Friday, September 20, 2013

Beginners Guide To Project Management
Part 18 - Are We There Yet?

This is part 18 of the Beginners Guide To Project Management and it is about schedule control. The ultimate purpose of this is for you, the Project Manager, to be able to answer the million dollar question "When will we be done?" (or like the kids like so much to say: "Are we there yet?"). This is something that should be constantly on your mind, the Project Manager's mind, even prior to starting the work on your project.
But what do you need to answer this question? And if you can answer this, are you in control of your project, that is, is this enough for you to be in control? This is what this article is about.

Previously on the Beginners Guide to Project Management:

Introduction
Initiating
Planning

Executing

Is this enough?

The truth is you need a lot more than just answering this question in order to be in control of your project's schedule, right? Knowing that our planet will no longer exist within 7 billion years (or so) doesn't make you feel more in control, does it?
(Note: There are lots of estimates like this but here's one for you on Scientific American, just in case you're curious enough about the topic, and they do vary - that's way they are estimates. But so is the answer to the question "when will we be done" regarding your project).
So why do you need so bad to know when will your project end? In a nutshell, because, if you know that your project is late, you can propose actions to speed it in order to deliver by the initially expected date.
Suppose you started your project's execution 2 weeks ago (early September) and that in the plan you were expected to conclude it on December 31st. Also suppose that you had some problems with a supplier (or assigning a certain team member or approving a purchase order or allocating office space or whatever reason) that, according to your best estimation, will have a 1 week impact on the overall project duration - so you will deliver 1 week later. Now that you know this, a lot of things can happen, such as:
  • Nothing: because it's all the same if the project ends by the initially estimated date on the project plan or not: it's just not worth the effort
  • Address the issue: if it's a supplier that's the problem, can you pressure him? can you change the supplier? can you build yourself what you were buying from that supplier? will it do any good? can you afford addressing the issue?
  • Long tail project: when you split your project (please check the article "Troubled Project") into two projects: one that will deliver the "must-have" functionality/products/services by the initially estimated date and a second project with the "nice-to-have" functionality/products/services
  • Drop requirements: if you have to meet both duration and costs estimation (so no long tail project is possible) maybe you can drop some of the requirements...
  • Crash: add more people to the team if you can afford it and if it will make a difference in terms of the overall duration (more people doesn't always mean less time)
  • Fast track: maybe you initially planned some tasks to be run in sequence when they can actually run simultaneously (with a probable risk increase)
I cannot think of any other course of action, but I'm sure there must be others. Please let me know if you can think of any other course of action.

Project performance data

But how can you know if you're late? And how can you know exactly how late is your project? For that you have to somehow collect some project performance data, right? But how will you collect project performance data? How often? How will you work that data? What will you report on that data?
In order to tackle this you must have it already embedded, at the latest, into the project plan. It can be that your organization has this solved for you because in your organization "all marketing project are managed according to Scrum" - but included in the project plan nevertheless
In any case, your project management plan should indicate how you tackle this. For instance, suppose your organization does use Scrum for any Marketing project. So at the very least, you'll address this at your daily Scrum standup meeting when your teams members get to the "What did you do yesterday" part, right? And you'll probably build a burndown chart, right? But what kind of burndown charts will you use?

If you check this burndown chart, you'll find it a bit different from the usual, so if plan to use it you'll have to get the necessary data from your team to build it.
The very same thing is equally valid to any other approach you take included.

What to do?

Once you estimate your gap between:
  • the end date of your project in you project management plan
  • the end date of your project using your project performance

There are some things you can do, namely:
  • Preventive and corrective actions
  • Change requests
  • Performance reports
  • Project plan updates
Depending on the context, some of these will make sense - or not.

Preventive and corrective actions

There could be some changes you could implement that could put the project back on course. There could even be some preventive measures that could make sense These could be either project work related actions or even actions related to the management of the project.
For example, maybe the decision process is taking too long and you could propose just 2 levels of decision: you could decide alone on any project cost increase up to 1.000 USD or take it to the sponsor if over 1.000 USD and he would have the autonomy to decide alone on that. Cool, hein? Anyway, you could propose such a preventive action and it would be an action in the context of the management of the project - not in the project work itself.

Change Requests

If such actions have an impact in the project (and they should have because we're talking about schedule control), there should be a change request. This request could be very formal, like a form you'd have to send to a Steering Committee for approval; or it could something very informal like sending an email to the project team and the sponsor saying "we're going to do this this way instead of what was initially planned".
These change requests also include the ones that are approved and that you need to include in the project and the project plan.

Performance Reports

Knowing what's going on in your project, you should probably want to report on it. Usually, the project team and the sponsor are the targets of these reports but there could be others. The metrics that will be used and the respective detail will vary with each project and should be explicit up from in the project plan.
For instance, you probably won't ever use Earned Value Management and Scrum at the same time. But if you decide to use Earned Value Management, the detail and extent should be in the project plan also: is data collected online? Daily? Weekly? Are you to report on the Work Breakdown Structure on the first 3 levels of the Work Breakdown Structure? Or all levels? These make a difference and will require a different level of administrative work (yours and your team) that must be taken into account.

Project Plan Updates

Finally, the project plan should be updated anytime there are changes to the project plan - this makes perfect sense, right? In which case, people should be informed. And you should also make sure that they do know about the changes. Remember that just because you sent an email that doesn't mean that i) people actually read it and ii) even if they did, it doesn't mean that they did understand it.

Conclusion

There's nothing much to this schedule control thing: you just have to know what's going on with your project and be able to report on it. Pretty simple. But not always easy. The wrong approach on this for any given project can be:

  • really costly (because it requires a lot of time from your team updating time sheets and alike)
  • it could mean a lot of administrative work (because performance information is daily updated in this particular project - but is requires manual work), or
  • lack of information (because you're not collecting all the performance data that you need to build the required performance information for this particular project).

So, yes: schedule control is pretty simple. But not easy.



Images from http://contrarianedge.com/ and http://www.mitchlacey.com/

No comments: