pmStudent

Matt sent a particular system engineering document out for peer review. 

The quality assurance analyst on the project sent an email out asking the SE lead which version of the document template should be used to judge Matt's with.

Email chains later, it turns out Matt and the other engineers didn't know about any universal template that was to be used...they started with examples from previous projects that looked applicable.  There was an unofficial "official" version that someone cooked up floating around.

Now Matt is looking forward to reformatting his document into whatever the "official" format finally ends up as.

What is Project Quality Management?

You can find definitions all over the map, but to me it's really about 3 things.

1) Continuous Improvement

This is not a one-time, check the box event.  This is a continuous process throughout the entire project.  You can check a box when you do scope verification, but in the meantime QM is about making sure the activities throughout a project's life span are efficient and effective towards the end goals.

2) Consistency

In the anecdote about Matt, the project had at least one dedicated person who was solely focused on QM.  Or at least they think they are.  QM is more about prevention by optimizing the process than that.  The audit of output should be focused as feedback to optimize the process, not as the only way of managing quality.

The quality role should have ensured the engineers had a consistent template that made sense, had their input and that of the relevant stakeholders, and clearly noted which parts could be customized and which parts are critical to the consistency of the process.

3) Ensure the Project Meets or Exceeds Stakeholder Needs and Expectations

If having a consistent template doesn't add any value by ensuring requirements are met or by optimizing the activities, what good is it?  Are you pigeon-holing everyone into a common template just for the sake of it?  Does it take them twice as long to use your template because they are contorting their content to fit?

That said, I do see great value in having well-defined templates for many project activities that can be used from project to project and different areas within the same project.

I am sure that some of you reading this right now will disagree with my definition of quality.  Perhaps I have left something critical out.  Don't worry, I'm used to people disagreeing with me.  Just leave a comment and let's talk about your views!

I had a conversation today that reminded me about a mistake I see project managers make from time to time.

When creating a Work Breakdown Structure and the subsequent Basis of Estimates, some will use documentation as the key deliverables.

The logic goes something like this:  We don't have anything tangible to deliver except these documents, so hey, let's take all this other work, find which document it most closely relates to, and use that to hang our hat on.

This creates a lot of problems.  

First, it's not accurate.  You didn't take 600 hours to create that document.  Rolling up your work this way gives the illusion that by axing that one document from the scope, it will save that much time and effort.  Wrong!  Most documents, especially in a project with a heavy IT focus, are created only as the 'documentation' of a lot of other time and effort.  In my area, designing and creating build scripts, ERDs, data models, etc. might result in being ABLE to produce a good DBDD (Database Design Document) but all those pieces of scope are separate deliverables in and of themselves.

Second, it confuses your scope and the ability to create and track meaningful tasks for your team.  Creating the document is not the primary goal; the primary goal is delivering all the work (code, designs, etc.) that eventually gets documented in a formal fashion.

Thanks for reading my rant.  A penny for your thoughts?

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