Project Management


Ranting and raving about project management and systems engineering.

About this Blog


Recent Posts

The Problem with Project Management

The Problem with Project Management

The Problem with Project Management

LinkedIn Recommendations Are Easy

The Catch-22 of Project Management Certification and Experience

Why Change Control Is Important

Categories: Change Management

I received a question from someone dealing with a discrepancy between how EVM reporting has been presenting progress versus actual progress.

Essentially, the scope and cost of the project has increased, partially through estimation problems and scope changes over time.

However, it appears they are still reporting against the same Performance Measurement Baseline (PMB).

The sooner you can transparently communicate with key stakeholders, the better. 


It sounds to me like what should have happened is a re-baseline with all parties involved so everyone understood the reasons why and you could go get more funding now. If you are using EVM, the forcasts should have been showing a slipping SPI and CPI this whole time, in which case everyone would know there is a problem.

Does re baseline mean:
Drop in progress percent complete, say reporting 80% in revised scenario versus previously reported 90%??
If not, then what does this rebaseline actually mean?

A rebaseline only happens when everyone agrees there has been a significant change in scope, cost, or schedule.

Scope increases should only be accepted by the contractor via a contract modification and/or formal change management process. Do you have a Change Control Board (CCB) consisting of the sponsor, key stakeholders, and project leaders? Ideally, all of these changes in scope would have resulted in a Change Request (CR) to the CCB, and once approved the Performance Measurement Baseline (PMB) is updated. This way you are only working on approved scope and your EVMS has value. That said, baseline changes shouldn't happen for estimates that were just off. They must be from CRs which are tied to a clear change in scope outside of the project's control (new customer requirements, massive unexpected procurement cost differences, new regulatory requirements, etc.)
It's always more painful the later it occurs. At this point if I were in your shoes, I'd have a CR describing every individual reason for a baseline change, work it through the CCB and manage change formally via the CCB from here on out. It may be an "ask for forgiveness" moment right now where you have to be honest and open, admit mistakes humbly, and show the plan to improve going forward.
Posted on: January 30, 2012 03:48 PM | Permalink | Comments (0)

When A Team Feels Micromanaged


Trust and When You've Moved Their Cheese

The teams must trust the project manager if they are to work together effectively. If new practices have been introduced recently, it's probably more of an organizational change issue than an issue specific to project management itself. You moved their cheese!

You must establish trust with your teams and stakeholders before pushing them through change. If they are not bought in to you and the change beforehand, you will fail. As I wrote about in "New Project Manager: How to screw up in the first 60 days", flying in, cape waving to 'rescue' your team is not the right approach. It's a good way to screw things up by sending the message that you think the way they have been doing things in the past is stupid.

Tracking At The Right Level

I've also seen this happen when the project manager tries to get too fine-grained in terms of schedule and status updates. My personal opinion is that using details when planning and estimating is good, but trying to have that same low level of detail (especially in a waterfall environment) is going to drive teams nuts.

And frankly, that drives me nuts too.

When you have an agile process like Scrum or Kanban in place, it makes it much easier to go down to these lower levels of detail. This is because you are only worried about being able to visualize the work and make sure everything is getting done....if you try to ask team members to split hours worked across individual tasks, it can become very taxing quickly. Every minute your teams have to spend each day trying to track their time is a minute lost - but more importantly it's frustrating to do!

That level of tracking implies a lack of trust from management, and people start cracking jokes about which charge code to use from the time they leave their desk to the time they get to the meeting.

For example, in our last release one of my teams probably worked a total of 100 or so individual tasks. Most team members had no more than 4 'buckets' to split their time up with.

There is a level of tracking that adds value, and once you go down too deep the value drops off, and the overhead cost increases. Furthermore, the more confusing it is for your teams, the less accurate your time tracking will be.

Posted on: September 02, 2011 12:02 PM | Permalink | Comments (6)

Getting the Stains Out of Your Requirements

by katerw via FlickrHaving taken over a project, I find myself in the awesome position of needing to revise requirements with my customers that are pretty obviously in need of some spring cleaning.

Here are some tips for your own situations where you must "scrub the stains" out of a set of requirements, as opposed to dealing with change management on one specific requirement.

Make it Easy

We use DOORS to manage our requirements.  For me, step 1 is to export from DOORS to an excel file.  Getting these requirements into a format people are comfortable with is very important.

Next, I trim away the fields that don't really matter for what I'm trying to do, and then copy/paste the requirements into a blank Word document.  The reason for this will be come clear in a moment.

Track Changes, with Comments

I turn on the "tracking changes" option in Microsoft Word, and go to it.  Whenever a change is made, a comment accompanies it.  I speak to my audience, the customer, so they will easily be able to understand why I am proposing some changes.  In this case, I want to add clarity and also specify some functionality that has become known as a user need over time, but wasn't captured in the original requirements.

Review With The Team

I always like to review any requirement changes with my teams before proposing them to the customer.  This way, I can be sure I'm on the same page as my team members and there aren't any communication gaps about the needed functionality.

Many times, the understanding I've gained about new wants and needs comes directly from my team members, who are interacting with the customer and future users of the system.  It would be very bad if I had a misunderstanding on a particular requirement and ended up making that part of the baseline, when it's really describing the wrong thing.

Meet with Customer

Next I meet with the customer to ensure the changes I'm proposing make sense to them.  The comments I did earlier come in really handy, and the better they were, the easier this process is.  In my environment, I prefer to do this before having it come up at a Change Control Board (CCB) meeting as a change request.  I want the customer to be knowledgeable about the proposed changes and see the value in them before having to make a decision.

Change Control Board

The final step is to "make it official".  If you don't have a change control board in your project environment, you should set one up.  It doesn't have to be complicated, but it does require that everyone on the project understand that changes don't get made to the project baseline unless they are approved by the CCB.  

The customer and sponsor should be voting members, and in my environment the customer is the chair of the CCB.  That means they have the final word on whether a proposal will be approved or not.  If you are in a different contract environment, it may be a CCB internal to your own company/contract you are interacting with.

Like this? Share it!
Posted on: April 27, 2011 07:48 AM | Permalink | Comments (1)

How Changes Ripple Through a Project

Categories: Change Management

Change management is tough.  On a large and complex project it is a difficult challenge, even with the best processes in place that everyone adheres to in a perfect scenario.

I saw a tweet recently that asked "Why are Change Requests an output of Plan Procurements process, but not of any other planning process?"

I answered with a question....Why doesn't the PMBOK have a dedicated knowledge area for change management?

This is an area that deserves much more attention than it receives.  I manage two project teams that are developing 4 subsystems within a very large multi-level and complex project.  There are several segments of the project, and when one (say a spacecraft vendor) makes a change it often impacts my teams who are developing pieces of the ground system which will receive, process, and store this information.  Everything has to be in line, and when you start crossing contract boundaries it gets really difficult at times.

Even within my own teams, it can be difficult to properly assess the impact of a change.  One team decided we should make a change because as far as they knew, this change was only local in scope.  The next day I found out one of my other teams was a user of this data and so we couldn't make this change.  The impact would have been very high.

Change Management FAIL

As a result of this lesson learned, my team and I are putting some new processes in place.  The trick is to make them as lean as possible while still delivering the value of being able to fully understand the impact of change.  We'll see how it goes.

As a project manager, you will find yourself coming across 'lessons learned' like this all the time.  The question is, what are you going to do about it?  Do you shrug your shoulders and say 'Yeah, I hate that.  I guess we'll do the best we can to avoid it in the future.'

That's not good enough.

When you find issues like this, talk to people on the team and come up with a solution.  Then implement it.  Right away.

photo by Chill05 via Flickr

Posted on: August 21, 2010 10:54 PM | Permalink | Comments (4)

I have made good judgements in the past. I have made good judgements in the future.

- Dan Quayle



Vendor Events

See all Vendor Events