pmStudent

Everyone makes mistakes. Even if you are supposed to know a lot about a topic, it can be nearly inevitable that you will make a mistake or forget something you should have known.

-Josh
pmStudent e-Learning

The team is awesome.  They are smart, motivated, and want to do a great job.

The last project manager?  FAIL

You're the new project manager, and you're speaking to variances on a baseline that forgot what reality was last fall.  The WBS is structured to look nice, not to model the actual breakdown of work on the project.  The schedule was made to be convenient for upper management, not to be a representation of the actual work that has to get done.

Arrrrgh!

How To Cope

The first thing is to get a handle on your scope.  Without that, trying to manipulate a schedule is futile.  The WBS (Work Breakdown Structure) to the rescue!

Scared at what the reaction of the developers will be, you decide to sit down with them and create a WBS together anyway.  Oddly enough, a little while later you have a draft that looks pretty darn good, actually.  The team is already getting used to the idea that they can glance at this diagram to get a clear sense of what they need to deliver.

Now that your structure for work breakdown is solid, you can start breaking down the deliverables into the tasks it will take to produce them.  I do this in a BOE (Basis of Estimate).¹  Then, you can start to produce a schedule (at least a working schedule) that really tries to model reality.

Depending on the project environment you are in, you may be able to re-baseline the project right away or you may have to wait.  You may have to speak to variances for a long time however.

• Be honest - If you think the previous estimates were plain wrong, say so.  "Now that we know more information about x, y, and z our estimates are closer to reality (and well done in the BOE too).
• Find out what you can - In this situation it's helpful if you can find out what assumptions were made before you arrived.  In some cases there will be no documentation and you may have to guess.
• Be good to the team - I have seen some people in this situation try to blame the team for an unrealistic set of estimates, decomposition of the work, etc.  Nope.  Everyone contributes, but this is ultimately the PM's responsibility.
• Wow them with the "new way" - I don't normally recommend changing anything within the first 30-60 days of taking over a team....unless it's a train wreck.  In this case, your goal should be to wow both the project team and the other stakeholders external to the direct team with turning a fuzzy mess into crystal clarity.

What advice do you have for others in this situation?  Have you been in this situation yourself?

-Josh

¹ WBS Coach, WBS and BOE integration on page 50 of the textbook

• Super Taskers Study (PDF)
• Super Taskers TIME article

My posts:

• The woes of multi tasking in project management
• Multi – tasking, Covey and TOC
• Do Your Project Teams Suffer From Chronic Media Multitasking?
• SCRUM Concepts in Traditional PM

-Josh
pmStudent e-Learning

I am in the process of a paradigm change for a project team I was recently assigned to.

I have discovered (once again) that methodology matters, but perhaps not in the way you are thinking right now as you read this.

What I Don't Mean

No, I'm not saying that Scrum or CCPM or Waterfall are "the" best method of managing projects.  When people start talking about how one methodology is better than all the rest, their perspective is often clouded with ideology.

What I Mean Is...

The processes you use to manage projects does matter.  Mostly, the project environment, team(s), and stakeholders will lead you towards a way of managing projects that is a hybrid of the well-known models out there plus lots of organization-specific pieces that you won't find in any manefesto or "how-to" book on project management.

My Example

For my example, I am working on a large federal contract with a small team who is responsible for 2 of the 8 or so subsystems within one segment of the project.  The project as a whole, and the individual contractors are using traditional waterfall methods and EVM, with multiple releases of the subsystems (a.k.a progressive elaboration).

My team has had experience with Agile methods in the past, and they love working that way.  So do I.  So.....

We have collaborated on a hybrid approach that uses some of the aspects of Agile (Scrum in particular) that we can gain clear value from while throwing aside some of the other aspects that just won't work well in our environment.

For process, we will be doing 2-week sprints with the standard major releases, product backlog, and sprint backlog.  We did our first sprint planning session today which went awesome, and we'll do informal retrospectives too.  We will have daily tag-ups for 15 minutes each morning to ask and answer the following questions:

1. What did you do yesterday and how much is left on those tasks?
2. What will you do today?
3. What worries or obstacles can you see currently or on the horizon?

For tools, I started with a Scrum template from Petri Heiramo from Digia and modified it heavily to fit our unique needs.  I added resource-loading capabilities to the template and other key pieces of functionality, including a tab which translates the Scrum-ish progress updates into a format I can easily update our main project schedule with.

Not Throwing Out the Baby, But Some of the Bathwater Must Go

We are not doing the standard software development you might see with Scrum. 

We won't have discrete releases at the end of each sprint, so we've thrown that part of the Scrum methodology out.  Instead, each sprint gets us closer to a major release with clarity of planning and the ability to respond to the changes we enjoy on a daily basis.  Our subsystems are almost entirely database systems, but they support and integrate with all of the other subsystems and so many changes in those subsystems impact us directly.

Which is why I'm also throwing out the idea of a sprint baseline (sort of).

We've decided that after the initial sprint plan is finished for a given sprint, I'll save it as a baseline but then a working copy of the tool will be modified on the fly, daily.  We'll remove and add tasks, adjust estimates, whatever it takes to respond to the constant changes around us.  We'll get better at estimating as time goes on, anticipating potential changes and rework coming from outside the team, etc.

So Agilists will say we're not doing "real" Agile.  And Waterfall enthusiasts may glare at us.  So what?  I've ensured I can meet or exceed expectations for advanced and short-term planning, and excellent status reporting.

We've worked out a promising process that meets all our needs and my team and I are jazzed about.

And I couldn't be happier.

Image:  Cookie cutters by G & A Sattler via Flickr

What do you think?  Got a comment on what I'm doing, or a story of your own to share?

That's right.

Have you ever noticed how the best way to learn is to watch people who are really screwing it up? 

Call it the Tool Time Phenomenon.

I've been reminded recently that if you really want to destroy your chances of success, the best thing you can do is neglect communication.

Specifically in this case, if you want to make a mess of things be sure to rely on email communication with your team for simple one-sentence questions even though they are about 20 steps away from your desk. 

Whatever you do, don't have weekly one-on-ones with your team to discuss their concerns and feedback, talk about status of current work, and future work and milestones that are relevant to them as an individual.

Oh Oh!  Be sure to undervalue the importance of team tag-ups too, and when you do have team discussions, be sure to bog it down by making everyone sit through your gathering of status updates (because you didn't do that in a one-on-one).

When there are activities going on that are related to your team's work, be sure to not share it, even as an F.Y.I.  No, instead you should figure that if you can't think of how it impacts their work in some direct way, there's no reason for them to know anything about it.

What other lessons are waiting out there for all of us?  Have you witnessed a Tim "The Toolman" Taylor performing some educational magic on what not to do with regards to communication?  Do share!

-Josh