Make one person responsible for each activity

Each week, project management veteran Tom Mochal provides valuable advice about how to plan and manage projects. Tom first describes a common problem scenario, based on real-life situations, and then offers a solution using practical project management practices and techniques.

The dilemma
I met with Ted last week to discuss his project to install a standard manufacturing package at our new plant. Ted had managed to get his project back on schedule after some initial difficulty but was now starting to fall behind again.

“I think we are doing a lot right,” Ted said. “But as we are getting to the end of the project, I’m asking the team to do quite a bit of multitasking. As a result, the team is having difficulty completing their assignment on time.”

“It’s not uncommon to have a rash of work to complete at the end of the project,” I said. “This is the time where discipline and time-management skills are so valuable. Tell me more about why the work is falling behind. Does everyone know what’s expected of them?”

“I sure hope so!” Ted exclaimed. “I’ve tried to make it simpler by dividing the group into two subteams. Each subteam is responsible for about half the remaining work.”

“That sounds reasonable.” I replied. “What does your team say about missing their deadlines now that the project is so close to completion?”

“That’s one of the frustrating side effects of having two subteams,” Ted sighed. “I’m trying to give the teams maximum flexibility to complete the work however it makes sense. Now, since I am assigning work to a team, I don’t really know who to hold accountable when deadline dates are missed.”

I could begin to see a problem. “Ted,” I said, “you may have taken the team concept a little too far. Even though the work is given to a team, you still need to assign someone to be responsible for each activity. When people are working on multiple activities at the same time, it is especially important to have someone accountable for the work.”

Mentor advice
In a perfect world, all teams would understand what is expected of them, and the members would all hold themselves accountable for ensuring that the expectations were met. These types of mature groups are sometimes called high-performing teams.

In the real world, almost all teams fall short of this idealistic goal, and people don’t always understand what is expected of them. In many cases, they overemphasize certain activities to the detriment of others.

If there are problems, no one may step up to deal with it. In the worst case, anarchy might break out as people thrash amongst various activities, without the focus needed to complete any of them on time.

Just as a project needs one project manager, so each activity needs one person assigned to be responsible and accountable for ensuring the work is completed on time. If there is only one person assigned to the work, the responsibility naturally falls on him.

When activities are assigned to multiple members, one person still needs to be responsible for ensuring the work gets done. One person is responsible for providing status reports. One person can escalate issues and scope-change requests. There is also one person who is accountable when work is not completed on time.

In Ted’s case, he has reorganized his team so that they can each focus on their portion of the remaining work. However, he has opened the door to a potential loss of focus by not assigning one person to be responsible for each remaining activity.

Of course, Ted does not have to assign the same person to be responsible for all tasks. He can assign each of the members of the subteam to be responsible for specific activities. In this way, each activity has one person to make sure the remaining work gets done on time.

If they are accountable, they will also have an interest in making sure all potential roadblocks and issues are identified, addressed, and overcome, so that the work is completed successfully.

Project management veteran Tom Mochal is director of internal development at a software company in Atlanta. Most recently, he worked for the Coca-Cola Company, where he was responsible for deploying, training, and coaching the IS division on project management and life-cycle skills. He's also worked for Eastman Kodak and Cap Gemini America and has developed a project management methodology called TenStep.

Unrealistic project estimates: The IT consultant as an enabler

Takeaway: All IT consultants have given clients unrealistic estimates at one time or another. Get tips on how to resist the pressure to give ad hoc estimates.

Here’s an all too familiar scenario:

Bob the client calls and says, “We need to add this small feature to our application. How long will it take?” You respond that you need to draw up some requirements and talk to users, but Bob counters, “Oh, just gimme a ballpark estimate.”

The gears start turning in your brain as you imagine implementing the feature as described. Your natural optimism thinks you could complete the work in three days, but you know you can be overly optimistic, so you answer, “Two weeks.”

Guess what? You’re still short. You forgot these important factors:

• Requirements. Your client contact, whether they’re the CEO, CIO, project manager, or whomever, cannot have a complete picture unless she or he is the only user — and even then it’s dicey. Besides, there’s no guarantee that what you took from their brief description even matches what they meant.
• Design. You don’t want to jump in and start cowboy coding without a proper design of each component. I’m not talking about flowcharting everything or generating piles of UML that nobody will ever read again; your design needs to be flexible but well thought out. Even though this seems like it adds time to the project, failing to do this step adds even more time in the long run.
• Testing. I’m a big believer in writing your tests before you write the code to satisfy them — or at least, in parallel. This is another step that saves you time down the road.
• Iterations. No matter how well you define the requirements up-front, somebody will forget something important or something nobody even knew. You need to build in time for providing prototype versions so the client can use the product and provide feedback that drives new requirements.
• Documentation. A system that isn’t documented will be reinvented. If you want the project to have any shelf life, you need to provide usage instructions for people you may never meet and put enough comments in the code that you’d be able to understand it even if you hadn’t written it.
• Training. No matter how well you write, users may not be able to grok what’s going on without some personal guidance.

Taking shortcuts that cost more time in the long run

Consultants often leave out some or all of the above steps in an attempt to provide results quickly. Bob may be impressed when he gets the new feature in less than a week, but pretty soon, he’ll find out that the project isn’t quite done yet. In fact, you’ve only completed the first iteration, and even that was half-baked. The project will probably drag on for months or even years, as you tweak the features, fix the bugs, and give the users the same instructions over and over again.

So, why do consultants take shortcuts that make the journey longer? Here are four reasons:

• Client pressure. Bob wants you to give him a low number, so he can justify the work. You don’t want to disappoint Bob, and you want him to approve the project.
• Competition. If you aren’t the only bidder on the project, you want to be the lowest bidder so you get the gig.
• Hubris. No matter how much you pad an ad hoc estimate, it still isn’t worth the air that it’s written on. But once you’ve stated a number, your pride and your standing with the client won’t let you admit that you were wrong. So you cut corners.
• Pure evil. Some consultants get the client on the hook by intentionally engineering the project to require follow-up work after it’s “done.” Those consultants give the rest of us a bad name. (They should really read my column, “An independent consultant’s code of ethics.”)

Fending off pressures to give ad hoc estimates

I have three recommendations for how to resist these pressures:

First, consultants have to be aware that these pressures exist. When I was a newbie consultant, I had no idea why projects always took longer than expected — my estimate always seemed reasonable to me at the beginning. Learn from past projects — what went well and what didn’t, both in your experience and in the experiences of others.

Second, consultants have to educate clients on what a well-executed project requires. Clients need to understand that by taking a month instead of a week, they’ll get a finished product that meets their needs instead of one that does exactly what they said but not what they meant. And even if it does require modifications after delivery, they’ll be easier to implement without breaking something else.

Third, consultants should not give ad hoc estimates. If your client won’t stop bugging you until they get one, then say, “sometime between a month and 10 years” because frankly, that’s about as precise as you can be without more information. Instead, you should push for approval of an exploratory project to establish requirements and compute a decent estimate.

Building a reliable reputation

Unfortunately, because so many self-styled consultants are willing to cut corners, they’ve set the expectations in clients’ minds about what estimates mean. The more intelligent clients have come to expect that the project estimate will be far less than what’s really required when all is said and done. So when they receive a more accurate estimate, they’re likely to think that the actual timeframe for having something usable will be much longer. You need to build a track record of reliability before your client can trust your prognostications.