PM Practice: Tips for Tasks

Sorry … I should say ‘activities’ … not tasks. Pardon my non-PMI-speak.
Early in my coaching career, I worked with a bright project manager on developing his schedule. We talked a little about how to create a WBS and then how to define activities. I gave him those steps as an assignment and left him to it. When we met again, I was surprised to discover that he had no idea how to structure work. His activities ebbed and flowed in different directions. Some bore no relationship to the project, while others seemed to bleed into each other. Imagine defining activities for a dinner party. This fellow would have included activities like:

• “Prepare ingredients in the fridge” (what about the ones in the cupboard),
• “Buy and broil meat” (is that all you are buying … and aren’t there a couple activities in there?)
• “Bring salad to the table holding bowl with 2 hands” (the 2 hands part is a specification, not an activity).

Since then, I have thought more carefully about how I actually define activities so that I can talk about it to the less systematic among us (a group I identify with more as I get older). Apart from saying ‘it looks weird,’ here are some tips that have helped:

1. Activities involving performing work. It follows then, that activities should be structured using a verb-noun structure, as in “Do Something.” I worked with an event planning team that included activities like “Hotel.” I asked if they were planning to book it or build it.
2. Team members should be able to agree on what done looks like. Most people would say that “Write Draft Document” would end with an essentially-complete first pass at the deliverable, so that’s a good one. “Conduct Research” is trickier. Adding some specifications as a note to your activity may help.
3. Completing the effort associated with an activity should move the project measurably forward. “Execute Test Plan” should yield a performance result. I saw a plan once with an activity called “Develop Team.” I suggested they change it to “Hold Team Spa Day.” At least you know there’s no going back once you’ve had sweated it out in a sauna with your analyst.
4. Activities can be big or small. There is no hard and fast rule here, but I like each team member to focus on between 1 and 3 activities in a week, plus 1 project administration activity that remains open for the duration of the project. This usually means that activities will range between 8 and 60 hours of effort. Activities that are too small lead to administrative overload when you collect actuals from your team each week (which of course you do …). Activities that are too large are difficult to monitor for progress. “Create Requirements Document” can be a 6 to 8 week process with only 1 measureable deliverable at the end. Without a near-term checkpoint, activities like this long tend to get longer. I was brought into a project once that had spent 12 months on requirements for a supposedly 18-month project. I would break this activity into a set of iterations of draft and review.
5. If the effort transitions from 1 person to another, that’s probably a new task. “Write …” is one task. “Review …” is another.
6. A waiting time often signifies a break in tasks. Keep this in mind with projects that involve paint or concrete.

Activities are foundational to project monitoring and control. Getting a solid model of defined activities for the project will pay off later with fewer gaps or overlaps in scope and the team’s improved ability to deliver to expectations.

PM Laws: Who Defines Project Success?

When joining a project, I often ask team members to tell me a bit about previous projects. It helps me to understand their perspective on project work ... and keeps me from being (as) surprised later.

I'll ask them to tell me about a successful project and what it was that made it a success. I hear lots of reasons such as a great team, got to use new technology, build what 'I' wanted, requirements didn't change, ... When I ask why the sponsor or key stakeholders thought the project was successful, the confusion sets in. Some team members tell me that the sponsor was not happy with their successful project. More commonly, they simply don't know whether stakeholders considered the project a success or not.

This perplexes me. How is it possible for team members not to know what their stakeholders think about the project? This form of 'tone deafness' is a huge risk for project failure.
It's completely fine to be proud of the work we've done on projects, to enjoy being part of a particular team, or to get a chance to work on something really new. In the end, however, the success of any project will be defined and judged by those that initiated and paid for it. Just keeping this on the team radar goes a long way to ensure that the work being done is moving the project towards success.

So, the project you just finished ... was it a success? Says who?

I Like Projects Because I Like Change

Most change needs the coordinated effort of more than one person and projects are the construct for achieving results from our efforts.

By construct, I mean that the word 'project' is simply the taxonomy we use to describe a way of doing something. If someone tells you, "I worked on a big project last year," what are they really saying?

• I was a key contributor to a significant outcome?
• I was focused on achieving a goal in concert with others?
• I suffered under an inflexible regime in order to keep my job?
• What's on the lunch menu today?

Projects can generate strong emotional reactions - both positive and negative. But projects in their basic form are neutral. They are just of way of getting something done. So, how does it happen that some projects earn the nickname 'crowning achievement' where others are called a 'death march'?

I think it's because at their core projects are human enterprises. They contain all the necessary ingredients for both great (hope, dreams, ambition, conviction) and underwhelming (ignorance, prejudice, ambivalence, conviction) achievement.

Projects engage me because they hold so much promise. They can encapsulate achievement, whether it's building a beautiful house, a useful program, or a better health care system. But they're not easy. The world is chock-a-block full of processes, methodologies, tools, dashboards, and all kinds of 'techniques' to help manage projects. But still, they're not easy. That's because success in projects comes from things that are deeper than dashboards. They come from and through … us.

I've been fortunate to make a decent living helping other people's projects work better. It's fun and rewarding and it lets me get to know some pretty talented clients. I know a project team is on the right track when they let go of the idea that their success is measured by some dashboard ("if we code the status yellow, they'll stomp all over us!"), and start to visualize what they could possibly achieve. It has almost invariably been more than the team initially realized!