Forums

I got hit with a sledgehammer of a question from the President of our company yesterday. He was in one of "those moods" and pointed out that several of our projects are taking longer than anticipated. The discussion wasn't exactly form fit for Manager Tools' feedback protocol, but the underlying message was there.

Before the question, you have to take a little context. He's the President of a company that does contract engineering services. If our Engineers don't get the job done in the specified time, we don't get paid for that "overtime". He's an "ops guy". It drives him nuts when our internal people don't get things done on time because there isn't the same motivation.

Question: What motivates IT to get projects done on time?

Our Corporate IT group has done, and will do several large projects this year. They set a date and work hard to meet them. Sometimes this means other things (like break/fix work) suffer. Sometimes (OK, a LOT of time) it leads to bad morale and even resignations. I have a hard time "inducing" that kind of sufferage on my staff.

Your thoughts and comments are appreciated.

itilimp's picture
Licensee Badge

I work in IT and I can tell you it's different for all of us!

In my case I am motivated by a need to ensure IT is used to enable people to do their jobs more effectively. All too often IT gets in the way and becomes a hindrance rather than a help. Regardless of how cool it may be, if it doesn't help then we shouldn't be doing it.

I also get a lot of satisfaction out of a job well done; be that making a difference to the end user or making an improvement to the way I work (which is why I love this site!).

I am also motivated by a desire to improve the perception of IT. We can't do it all yesterday so it's finding ways of letting people know that in a way that doesn't annoy/upset.

In our case there are no financial incentives for completing projects, but if there were I think it would have a difference in the short-term for some of my colleagues.

A de-motivator is the number of projects that need to be completed at the same time as maintaining the live environment and knowing that the project will never be completed 'properly' because the moment there is a hint of most of the deliverable you are rushed straight onto the next thing.

Why do I feel like I've been ranting? ;)

cincibuckeyenut's picture

What kind of Project Management skills do your IT employees have? Do your projects include people that are also doing day to day support? How much and how often do functional specifications change?

As far as motivating IT, it is the same as everyone else. People get motivated by different things and you cannot sterotype an entire department or group of people in that regard, you have to figure out what works for each person.

This doesn't sound like a motivation problem. It sounds like it could be a problem with your project management practices. So if it is really something you want to address, I'd start there.

ctomasi's picture

I have five directs and three indirects (remote offices.) None are dedicated PMs. None are even close to being PMs. I do have two of the senior people going to a one day PM course in the next 30 days. We also have a pending FY07 group objective to create a more formalized project life cycle methodology. I've already got a way to capture the requests, we need to formalize the approval process, and definitely clear up communications before, during, and after projects.

The trickiest part I see is keeping the project on track when emergencies pop up, resetting expectations when schedules need to be adjusted, and of course COMMUNICATE!

Maybe you are right... this isn't a motivational problem. They are all hard workers, but projects that should have been done weeks or months ago keep getting stretched out, making us look bad.

cincibuckeyenut's picture

I would argue that just about everyone in IT is probably a PM whether they have the title or not. 80% of what we do is projects, either big or small. The trickiest part you have outlined is exactly what PM training will teach your people how to deal with.

PierG's picture

Chuck,
as you know in this fast changing world, it's not the metter of estimating it's a matter of doing what gives value to the customer FIRST.

I'm in the IT space AND in my group we have embrached 'agile methodologies' some years ago. Still hard to make our big big bosses understand and, we are going on one step up.

If you want, I'll be more then happy to talk with you about these ideas also in a private way, if this is going out of MT scope.

A good point to start is my blog :)

Ciao,
PierG

ctomasi's picture

That's what I love about this forum. I go home with a problem on Friday and by Monday morning I have several leads to follow to a potential solution. Thank you all very much! I will keep you abreast of the situation.

chaser's picture

I have never worked in IT before, but I have worked on many projects with IT people in the past. My observation is that often the group is set-up for a schedule slip when either the manager (i.e. president) edicts a date and expects a plan to be developed to achieve the date, or when an IT leader who is too aggressive and/or overly optimistic.

IT is one of those areas that everyone knows a little about and so therefore they think it should be easy. I mean I set up a wireless network in my home and I know how to use MS Excel....your job is easy. (I don't mean that at all...just trying to show how people think ;-))

I agree that PM training for IT people is critical, they need to learn the communication style, time estimation, and over cost and quality management to be successful.

As a black belt/master black belt for the six sigma program, I was directly or indirectly involved in literally hundreds of IT projects. Most worked at the end and would be considered successful and a few were out and out failures. Not one hit the original timeline or expectations. Maybe after I left they started hitting the original timelines....

Ryan

itilimp's picture
Licensee Badge

Actually, just to reiterate regarding the projects, although my job is system support I spend more than 60% of my time working on / managing IT projects yet don't have the official title of 'project manager'.

It IS just part of our work. In my department our project management training stems from the basics up to Prince 2. In our case management have started to realise just how project based our work and that of others is and are rolling out basic project management training (based on Prince 2 'Lite') across the organisation so that business owners can start to plan and consider IT in development of THEIR projects (all too often left to the last minute, "Oh, do we need a server for this? My go live deadline is in 3 days!").

It's that much easier to motivate yourself when you know people around you are being realistic about their plans and making an effort to think about things rather than just expecting everything to magically come together.

TimBryce's picture

Here is the problem your President has: he doesn't understand why
I.T. should operate any differently than any other part of the business.
Since his background is engineering, he understands concepts such
as step-wise refinement during design and blueprinting, parts
specifications, MRP, assembly lines and production control. In his
mind, the design and development of any product, including systems,
is a science. And he is right. But here is the rub: most I.T. departments
do not think this way. Instead, they project the impression that building
systems is a free-spirited art form. Consequently discipline and
organization in I.T. is lax and inevitably end up operating in a "fire
fighting" mode where they are always playing catch-up. I always kid
the I.T. people that if we built bridges in this country the way I.T.
departments build systems, this would be a nation run by ferry boats.

To gain his confidence and trust, you will need to first communicate
at his level, not in any technical gobbledygook. Frankly, he is not
interested in your technical problems, only in results. Second, if you
haven't done so, run the department like a business, This includes
structuring your development efforts by bringing discipline,
organization and accountability into the department. In other
words, treat systems development like a science, not an art form.

Hope this helps.

All the Best,

TheSafeOne's picture

Everyone that has posted on this topic has really good points that they present....

But I want to get back to the question that you originally presented to us...

There are several ways for any manager (you or your boss) to find out what motivates his teams.... but the real question that I think he is trying to ask is "How do I motivate the team to meet the goals that I have requested of them?" In this case the answer is pretty simple, the team needs to clearly understand why a given goal is being defined and needs to further understand the benefits or consequences of meeting or missing that goal.

If you want a group of people to work to a common goal they must all understand the parameters around that goal (the good and the bad). A Manager can't just say, "March down that road" and expect to have everyone singing while they are doing it... A manager must say that, "We are going to go down this road in hopes of meeting this because it will provide . If we miss this objective, the consequences are ."

By taking this approach the Manager is ensuring a level playing field for his team, allowing his direct reports to achieve a clearly communicated common goal, and allow everyone to share in the ultimate success or failure...

What are your thoughts on this?

itilimp's picture
Licensee Badge

[quote="TheSafeOne"]A manager must say that, "We are going to go down this road in hopes of meeting this because it will provide . If we miss this objective, the consequences are ." [/quote]

If I had a manager saying that to me I'd be singing AND dancing down the yellow brick road! Hear hear.

TheSafeOne's picture

[quote="itilimp"] If I had a manager saying that to me I'd be singing AND dancing down the yellow brick road! [/quote]

So does an ITIL Professional like yourself live in SoCal and happen to be looking for a job?

Hehehehehe

Nik's picture

This is pretty basic, but basic is good, if you ask me:

Make everyone on your team accountable for their skill at estimation. Get estimates from them, document those estimates, and document slippage and where it occurs.

For this to work best, you'll also want "phase" estimates, so rather than a "it'll take 12 months to build X and Y" you want the time it takes for each step. (That process alone improves estimates.)

Once you do this, review slippage and over/under-estimation a part of their regular review process, and possibly even part of a "scorecard" you keep for them. This will do two things: One, it will prioritize timeliness, good estimation skills and project management skills; two, it will give YOU the raw data you need to adjust estimates.

See, people are consistent. A developer who works with me is CONSISTENTLY dead-on when it comes to budget, but off by a factor of 3x on his time estimates. So, I can take his estimate, triple it, and I'll be right on 90% of the time. My users are happy, and so am I.

(To be fair, he's actually gotten a lot better at estimating, so now I just have to add 50% on the top of his estimates, or double it if he's doing something he hasn't done before.)

I also suspect that tying bonuses to on-time completion of projects might be a nice thing to do. The bonus could be non-financial (a party, a day off, whatever) if you don't have much wiggle room there. I hate to be the econ-101 type manager, but it's nice to get a solid "hey, that's good work" when people start moving in the direction you want 'em to go.

itilimp's picture
Licensee Badge

[quote="TheSafeOne"]
So does an ITIL Professional like yourself live in SoCal and happen to be looking for a job?

Hehehehehe[/quote]

<--------- ;)

akinsgre's picture

[quote="Nik"]This is pretty basic, but basic is good, if you ask me:

Make everyone on your team accountable for their skill at estimation. Get estimates from them, document those estimates, and document slippage and where it occurs.

For this to work best, you'll also want "phase" estimates, so rather than a "it'll take 12 months to build X and Y" you want the time it takes for each step. (That process alone improves estimates.)

Once you do this, review slippage and over/under-estimation a part of their regular review process, and possibly even part of a "scorecard" you keep for them. This will do two things: One, it will prioritize timeliness, good estimation skills and project management skills; two, it will give YOU the raw data you need to adjust estimates.

See, people are consistent. A developer who works with me is CONSISTENTLY dead-on when it comes to budget, but off by a factor of 3x on his time estimates. So, I can take his estimate, triple it, and I'll be right on 90% of the time. My users are happy, and so am I.

(To be fair, he's actually gotten a lot better at estimating, so now I just have to add 50% on the top of his estimates, or double it if he's doing something he hasn't done before.)

I also suspect that tying bonuses to on-time completion of projects might be a nice thing to do. The bonus could be non-financial (a party, a day off, whatever) if you don't have much wiggle room there. I hate to be the econ-101 type manager, but it's nice to get a solid "hey, that's good work" when people start moving in the direction you want 'em to go.[/quote]

Ugh...

Absolute estimating is really difficult for all but trivial problems. And padding estimates in the hopes that the estimates are low is a great way to see Parkinson's Law manifest itself.

I understand that estimates are important, but they're likely more important because a manager isn't used to seeing a predictable flow of value from a team... If you can provide a predictable value stream, then estimates are less necessary.

Also, shortening the time between delivery of value is a sure way to improve estimating, by making the work being estimated less complex; by providing more feedback upon which to improve estimating skills; and by framing estimates in relative rather than absolute terms.

Back to the original discussion... I think that the reason that most business has a difficult time with IT is because IT is viewed as having a dissimilar delivery mechanism. Should we try to improve our current model, or should we change the model to make it more consistent with other business areas?

-greg

Mark's picture
Admin Role Badge

I don't think the President wants an answer, and I wouldn't try to get him one. He's not speaking literal-ese, like IT folks often do.

Here's what he intended for you to hear:

Are you guys ever going to figure out that when we give you a deadline we expect you to meet it, or that if you give US a deadline we assume you will then as well?

Nobody would be surprised if jobs were cut because forecasts for sales weren't met... but that's just the sales force not meeting their time and work deadlines. Why is IT surprised when there are consequences when they're late?

If your staff don't like deadlines... they should do IT in a non-profit oriented world.

And, it appears that you need to significantly enhance your ability to speak your boss's language so that your estimates are both reasonable for you and acceptable to him... and then, start spending more time talking to your team about the importance of deadlines (insofar as your President thinks negatively about deadlines and IT when he puts them together).

Mark

Nik's picture

[quote="akinsgre"]Absolute estimating is really difficult for all but trivial problems. And padding estimates in the hopes that the estimates are low is a great way to see Parkinson's Law manifest itself.[/quote]

I mean no offense, Akinsgre, but I'd fire somebody who gave me that response. While adding some slough room is a good idea in any complex project, you should never just pad estimates in order to underpromise/overdeliver.

But I agree with everything else you said. It's incumbent on the manager to see his staff get BETTER at estimation and to provide the coaching and tools to do so.

Also, for especially risky projects (new challenges, exceptionally broad scope, etc.), it's entirely fair to tell the president that your estimate is pretty weak at the outset, and keep him informed as your estimations change. A stage-gate project methodology can be written into the contract/project plan to ensure that the client's expectations are met and that the company doesn't foot the bill in the end.

Derry's picture

Great topic and good responses. Some thoughts.

IT folks are a little different (lots of "C" and "D" types) and they like to solve/accomplish/complete things. So that's one motivator

On the Project Management side (this is the PM discussion thread after all)

Dates slip for a reason and poor estimating is only one of them - and usually not the most common (imho)

The primary reason that dates slip is because the estimates are made based on the work only - not on the work and the environment.

If IT people are assigned to 5 "top" projects, and they have no clear direction as to which is most important - then they will work on the one they want. If 10 people are assigned to multiple projects it is highly unlikely you will make the expected progress:
Tips on that:
Isolate and/or dedicate project teams (if you can)
CLEARLY define project priorities to ALL team members - at least you will deliver the most important projects on time!
Plan for interruptions/priority changes, in short what really happens. Don't "fudge" your estimates at a task level, if you do that then the task will take exactly as long as you fudged it to take "there is never any leftover fudge"

OK - getting too long - the idea is that they probably are spending the estimated amount of "effort" on the work, it's just taking longer because of all the other things going on - find these out and manage them or plan for them.

Also, are you telling your boss the impact of adding new projects - if all your team are busy then something must be getting pushed somewhere. I've found that if you tell management that the new project will cause delays and overruns in one that is currently in process, they often re-think. It is all past of the cost benefit and portfolio analysis.

Hope this helps

akinsgre's picture

[quote="Nik"]
I mean no offense, Akinsgre, but I'd fire somebody who gave me that response. While adding some slough room is a good idea in any complex project, you should never just pad estimates in order to underpromise/overdeliver.
[/quote]

Late response, sorry. I thought that was what you were suggesting? After re-reading your post, I might have misunderstood your intention. You said that you'd triple estimates to achieve an more reliable number.

Whether an estimate is being increased to "pad" or to balance a developers predictable under-estimating, I think that the result is that work expands to fill the available time.

Consequently, either way of doing estimates is going to result in inefficient use of time.

tlhausmann's picture
Licensee BadgeTraining Badge

Although this thread was idle...I am going to chime in. I have adopted a handful of best practices from Manager Tools during the past year.

TheSafeOne was spot on: when presenting a project to an IT group to let them know why the project is important. Our IT group staff meetings end with a waterfall report of what I learn at my meetings with the president and other officers of the non-profit operation where I work.

Combining effective staff meetings, waterfall reports, and the goals of our non-profit operation has made vast improvements. Although we still have operational hiccups -- our strategic projects are getting done on time and under budget.

Now a question: How much do IT managers in this group invest each year in IT staff training and development? What benchmarks do you use?