Monday, December 31, 2012

The Project Manager’s Cycle – Redux

“What does a project manager do?  What value do I add to your project?  It’s true that I don’t contribute directly to the product or service for which the project exists.  However, if I’m doing my job well, then I add significantly to the productivity and value of the team by improving communications, eliciting priorities, and focusing the team on the key deliverables.  Further, I am your agent, seeing that we perform to plan and communicating back when we diverge from it.”

Note:  I originally wrote this in April/May 2011 and it was intended to be the final post in The Project Manager's Cycle series, but on reviewing my archives today I realized that I never published it.  My apologies... and here it (finally) is.

The Project Manager’s Cycle includes these activities:
A baker’s dozen posts on the core project management elements of monitoring and controlling a project.  This series on The Project Manager’s Cycle been a pleasure to write and has also been beneficial for me.  I developed the outline of the series several years ago, but this journey required that I really flesh out the details, relationships, and components.  I appreciate all of my reader (yes, that would be you) who stayed with me through this.
A picture is worth a few words, it’s said, so I’ve tried to rough out the series in a diagram.  If I ever figure out how to make it available as a download, I’ll enable that.  In the meantime, leave a post or drop me an email and I’ll reply with a full-size PDF of version 1.0 of the diagram.  Next time I’m feeling ambitious, I’ll add the inputs and outputs, though I’m concerned that will make the diagram too busy.

We stepped on the ferris wheel together in January to start this ride.  We’ve gone around the cycle and now it’s time for us to step off.
What of this series has been the most beneficial to you?  Where have I not been clear and need to expand or improve the discussion?

Friday, December 28, 2012

The Schedule – Risk Buffers


“The first step in the risk management process is to acknowledge the reality of risk.  Denial is a common tactic that substitutes deliberate ignorance for thoughtful planning.”
                                                                                                                - Charles Tremper

With this post, we conclude the series on developing the well-formed schedule.  We have taken the WBS, which defines the project scope, added the task dependencies, estimated the effort for each task, assigned resources to each task, and resource-leveled the task assignments.  The final step to complete the well-formed schedule is to add risk buffers so that the schedule has the intended probability of success.
A schedule without risk buffers has virtually no probability of success.  Since you probably want to present a schedule with some probability of success, it obviously follows that you must add some risk buffers.  So now you probably want me to tell you how many and where.

I’ll briefly identify two common practices for identifying risk buffers.  The first is built from the standard risk management process.  The PMI PMBoK risk management process includes the step “Quantify risks.”  You’ve probably wondered what this means.  For risks that should be mitigated, determine the probability of occurrence (a percentage) and the time and cost that must be added to the project if the risk event occurs.  Let’s say for a specific risk you determine there’s a 25% probability that it will occur and that if it occurs it will add 12 weeks (I’m just going to deal with time in this example, but you can extrapolate for costs) to the schedule.  The 25% probability times the 12 weeks is 3 weeks, meaning that you should add a risk buffer of three weeks to your schedule.
Depending on a variety of factors, you can either add all three weeks to the end of the schedule or spread it in appropriate points over the life of the project.

You repeat this for all significant project risks.
A very common alternative to this approach is to use the Critical Chain approach developed and promoted by Elihayu M. Goldratt.  It uses a formulaic approach to determine the appropriate amount and placement of the risk buffers.

This overview is obviously too high a level for practical application.  But with this post I’ve finally presented enough of the PM foundation so that I can introduce some of the more interesting and complex concepts.  I’ll do this starting with a couple of posts on advanced quantification of the schedules, then maybe transition to more fully explaining the development of risk buffers.
It’s taken me two years of posts to get to “the fun stuff.”  What area of project management best practice would you like me to tackle?

Monday, December 24, 2012

The Schedule – Resource Leveling


“Happy people plan actions, they don’t plan results.”
                                                                                                                - Dennis Wholey

We are nearing the end of the series on scheduling basics.  We have taken the WBS, added the dependency chain, estimated the effort and assigned resources.  The next step to completing the well-formed schedule is to level the resource assignments.  This is done to:
  • Prevent over allocation of a resource within the project
  • Prevent over allocation of a resource across enterprise assignments
  • Accommodate non-productive time and absences
First, let’s assume the project is in an organization following best practices.  In that case, all team members record all of their time each cycle to specific project tasks and to operations, administrative, absence, and other non-project activities.  Your project management software integrates with these time records (or time is entered directly into the software, such as Sharepoint wih MS Project EPM, Clarity or Primavera).  In this case, you already have all of the elements in place to just “push the button” on your project management software to resource level the schedule.  You will then want to review and fine tune the results.

On the other hand, if you do not have the luxury of these conditions, you have more work.  For example, you will have to tune and adjust using heuristics to get the right productivity factor so that you don’t over allocate resources within the project;  and it will be much harder to track other assignments and activities to prevent over-allocation across enterprise activities.
In either case, this step will be repeated regularly over the life of the project.  Rescheduling and replanning are regular activities in the Project Manager’s Cycle.

In my next post, we’ll conclude this series of posts on the basics of creating the well-formed schedule by discussing risk buffers.
If you are not in a “best practice” environment, what steps do you follow to produce a resource-leveled schedule?

Monday, December 17, 2012

The Schedule – Resource Assignments


“Time is the scarcest resource and unless it is managed nothing else can be managed.”
                                                                                                                - Peter Drucker

We are now half way through the steps for creating a well-formed schedule.  In my previous post in this series, we added task effort estimates, but we have not yet added resource assignments, which we will now do.
Why add task estimates without considering the resource assignments and then immediately follow that step with the step that adds the resource assignments and then re-estimate each task specifically for the resource?  Let’s consider three scenarios:

For a small, routine project in a fully staffed environment, assigning resources may be a mechanical exercise (you’ve probably done this same type of project so often, the WBS was built practically from a template and you know exactly who is doing each task).  I’ll come back to this first scenario later.
A second scenario is more common:  It is a large project, but some of the resources are known (or the resource skill is known and easily acquired).  However, for some tasks, there may be choices or the resource may not be known until late in the planning cycle.

A third scenario could be a large project, but it is one where the resources are definitely not known and there could still be many negotiations about staffing options.  In fact, the budget, schedule and scope could still be under negotiation.  But a time and cost schedule is needed to get approval to acquire the resources.
For a best practice recommendation, it must be general to all possible cases.  Since it isn’t always possible to know the resources and sometimes it is necessary to have estimates without resources, the general case is to first build the schedule with estimates but not resources.  Then when appropriate, add the resources and re-estimate.

For the first scenario, you certainly can combine these two steps.  Just understand that you are taking a short cut and that in other circumstances or a different environment you will want to follow the best practice.
Getting back to this step, then, you have a partially built schedule with dependencies and estimates, but no resources (or possibly generic resources).  So start assigning resources to tasks (or substituting resources for generic resources), ignoring, for now, resource conflicts and over-allocations.  For each resource assignment, review the task (inputs, outputs, work products, completion conditions, etc.) with the resource and have them re-estimate the task based on their understanding.  Review with the resource any task where there is a significant difference between the original estimate and this new estimate to understand why.  Update the task estimates with these revised values.

Don’t be surprised to find that the new estimate from this step is significantly different from the previous estimate and that you may need to renegotiate budget and scope expectations.  You may even find that as you complete some resource assignments, it forces changes to other previous or planned assignments.  And be prepared for even more variance in the next steps.  That’s why this is a recursive process – it seems like you just keep starting over from the beginning.
But actually, we’re up to Resource Leveling, the next to last step in building the well-formed schedule.  This is the subject of my next post.

Do you have resources estimate their own tasks?

Wednesday, December 12, 2012

The Schedule – Estimate Task Effort


"If you are distressed by anything external, the pain is not due to the thing itself but to your own estimate of it;  and this you have the power to revoke at any moment.”
                                                                                                                                - Marcus Aurelius

As we progress through this series on the well-formed schedule, we have taken the WBS and added the task dependency chain, leading to the next step:  estimate the effort for each task.  Whole books have been written just on estimating, and I’m not about to attempt to tackle the depth and breadth of the subject in this post.  Today I’ll focus on pointers and essentials.  I expect a number of future posts on estimating.
This post – in fact, this series of posts – is about developing the well-formed schedule.  It therefore describes best practices and assumes you are using best practices.  Specifically, that you are using task effort estimates.  I have dabbled around the topic of effort versus duration estimating in several previous posts, but have not focused on it specifically.  And it is too broad a topic for me to address it satisfactorily today.  For now, if you are using duration estimates instead, it severely limits the benefits of your scheduling tools.  I’ll come back to the topic of effort versus duration estimating in a future (series of) post(s).

Stating the blatantly obvious, since we’re developing task estimates from a WBS, we’re well beyond the stage of Rough Order of Magnitude (ROM) and top-down estimating.  However, we’re not yet at a defined estimate (say, -5% to +10% expected accuracy), but which is where we expect to be when we complete this series of scheduling steps.  We are at the first of an iterative series of steps of successive refinement.  In addition, as I’ve stated in the past, an estimate isn’t meaningful without the related risk factors.  These will be incorporated into the schedule at a later step in this schedule building process, but that means you should be noting the sources of risk as you develop these estimates.  You should also document all assumptions that factor into the development of the estimates.

Ideally the task owner should provide the task estimate, but assigning resources to tasks is another step that will come later.  So at this point you will have to do the best you can.  If you are a domain expert, you might come up with this first set of estimates (though there are many risks with this).  Alternately, another project team member who is a domain expert could develop the estimates.  Another approach is to use several expert team members and the Delphi estimating method, which I’ll discuss in a future post.  The Delphi Method is particularly effective for a variety of reasons (in fosters team camaraderie, consensus and consistency of expectations, it is a successive refinement method, it exposes “gotchas,” etc.).  (See also Wideband Delphi Process.)
Delphi may be too onerous, so a good alternative is the three-point estimate, which I’ll also discuss in a future post.  This has many (but not all) of the benefits of Delphi, and it flows right into the advanced “scientific” scheduling discussion that will follow this series on the well-formed schedule.

One thing about the estimates at this point is that they should be “resource independent,” or at least resource agnostic.  That is, for this exercise don’t assume a specific resource will be performing the task;  instead, assume a generic resource skill.  Later, the individual task estimates will be refined based on specific task assignments, the next step in the process and the subject of the next post.
In fact, there are a number of biases that should be avoided at this point.  For example, do not bias for resource availability or skill;  and do not bias for (your expectation of ) task duration.  Next steps will adjust for the former and the scheduling tool will adjust for the latter.

However, it is appropriate to bias for “productive” hours (again, assuming you are estimating effort hours).  Productive hours are those hours that the project team member is working on project tasks and contrasts with (non-productive hours) administrative activities, vacation, holiday, sick time and other absences, etc.  If the team resources have to account for all their time when recording their daily/ weekly activity, then this may already be appropriately factored.  If not, you may have to make adjustments within the tool.  For example, assume a task is estimated at 40 hours of effort.  One’s first expectation is that this is a one week (five day) activity.  However, a person working on this task will also check email, spend time talking on the phone to their insurance agent, landscape supplier, or home repair technician.  They may take a training class.  They make take an afternoon off to attend a school conference.
Over a long project, you may not know specifically when resources will take vacations, but you need to factor in that they will take some vacation sometime.  Such small amounts accumulate over the duration of the project.  Therefore, it is advisable to adjust the scheduling tool so that a workday is only, say, 6.5 hours, rather than the usual eight hours in order to accommodate these variances over the full project duration.

Next we’ll add resources to the project schedule.
This is a lot of material to pack into one post.  Where have I confused you, what do you agree with and disagree with?  What would you like me expand on in a future post?

Wednesday, December 5, 2012

The Schedule – Dependency Chain


"Things derive their being and nature by mutual dependence and are nothing in themselves.”
                                                                                                              - Nagarjuna

In my previous post on scheduling basics, I listed the essential requirements to have a well-formed schedule, which is also the sequence for developing them:
  • WBS
  • Dependency chain
  • Task effort estimates
  • Resource assignments
  • Resource leveling
  • Risk buffers
This post will discuss the Dependency Chain.  The dependency chain obviously sequences the tasks in the order that you plan to perform them.  A well-formed schedule, though, adds some best practices to the typical attributes. 

A true dependency relationship between two tasks is when a work product output of one task is necessary to start or complete a second task.  When that condition is true, there is a dependency from the second task on the first task.  What this excludes are artificial or convenience “dependencies” to accommodate resource availability, resource leveling, or the PM’s view of “reality.”
Assuming you are using a decent scheduling tool, the tool has features to effectively address resource availability (calendars) and resource leveling.  Thus, if you use dependency chains instead of the appropriate features, you are diminishing the effectiveness of the tool to support your scheduling efforts and you are introducing complexities when conditions change (as they always change) and you have to reschedule.  To restate that:  if you follow the best practice, then you maximize the effectiveness of the scheduling tool and enhance your flexibility to respond to changing conditions.

As you will see over the next few posts, we will continue to build on the foundation of the WBS, now with the dependency chain, to develop the well-formed schedule.
Do you agree that task dependencies should be based on work products (including deliverables)?  Is there ever an occasion to base a dependency on anything else?

Tuesday, November 27, 2012

The Schedule - Basics


Success is neither magical nor mysterious. Success is the natural consequence of consistently applying the basic fundamentals.

                                                                                                - Jim Rohn

On completing my recent series on the Work Breakdown Structure (WBS), I promised to continue the series on project management fundamentals with The Schedule.   In this post, I’ll discuss the basics of a well-formed schedule, to be followed in future posts with advanced scheduling techniques and best practices.
A schedule is more than just a timeline.  Most “schedules” that I see are actually timelines.  That is, they are a graphic representation of what the PM wants the schedule to look like, how the PM wants the project to flow.  A well-formed schedule, in contrast, is how the PM plans for the project to flow based on a given level of certainty (probability).  It is for this reason that a (time) schedule (and equally a cost schedule) can only be done integrally with appropriate risk management.

A well-formed schedule is built in these steps and, if any steps are omitted, it is not a well-formed schedule and therefore is not reliable:
  • WBS
  • Dependency chain
  • Task effort estimates
  • Resource assignments
  • Resource leveling
  • Risk buffers
We’ve already talked about the WBS.  Over the next few posts, I will expand on these other necessary elements of the schedule.  In addition, there is an optional step to quantify the reliability of the schedule.  This topic is challenging to explain and probably requires a full book to do it justice, but I will at least address the high-points.

One final thing before I close this post:  If you follow these steps and develop a well-formed schedule, will that guarantee a good schedule?  The short answer is: No.  Ignoring the obvious path that “good” is subjective and the pitfalls that leads to, my point is that following the “process” or steps of producing a schedule does not compensate for experience or fate.  That is, if an experienced PM produces a timeline without resource leveling, they will not have a reliable schedule.  On the other hand, if an inexperienced PM follows all of these steps, they still may not have a reliable schedule.   There are lots of ways to produce an unreliable schedule.  And sometimes God just laughs.
Other references on scheduling:
                PMBoK v4, chapter 6 (Project Time Management)
                The Practice Standard for Scheduling v2

Monday, July 16, 2012

Los 33 – The Chilean Miner Rescue

Franklin, Jonathan.  33 Men: Inside the miraculous survival and dramatic rescue of the Chileanminers.  New York: Putnam, 2011.


Lusted, Marcia Amidon.  The Chilean Miners’ Rescue.  Minnesota: ABDO Publishing, 2011.


The Chilean miner rescue was, though now old news, one of the most sensational project management efforts of this millennium – sensational in the sense that it played out on the international stage in real time.  I’ve read these four books trying to get the PM story, but was sorely disappointed.  I’m aware that a PM involved in the rescue spoke at one of the South American PMI conferences, but I haven’t seen anything published specific to the PM effort.  I really expected to find something in PM Network or PMI Journal, but haven’t seen it yet.  If you know where I can find the PM story of the rescue, please post in the comments.

As for these four books, Buried Alive (Toro) is the only one I can recommend, but it is mostly a report of the public records and events.  Most of the story is what is happening on the surface, with very little insight from the Los 33.  If you can get past the exaggeration and sensationalism, 33 Men (Franklin) provides the missing story of what happened underground.
 
33 Men (Franklin) was the first out.    Attempts to sensationalize controversial relationships, to the extent of creating things that may not exist.  Not well written.  Not recommended.

Chilean Miners’ Rescue (Lusted) is a juvenile version for early middle schoolers.  Seems to follow the narrative of 33 Men closely, but sticks to the facts and leaves out the sensationalism.

Trapped (Aronson) is aimed at an older juvenile audience (late middle school or early high school).

Buried Alive (Toro) consolidates the public events.  Includes short interviews with two of the miners.

Saturday, July 14, 2012

The WBS - Intermediate

Two (or six) months into your project, you and your business owner disagree about whether a particular feature or component is included in the project.  You, of course, consider this controversial item obscure and expensive to include;  the business owner, in contrast, asserts that it is absolutely essential, the whole project is value-less without this item, and, further, that since it is in the original scope it shouldn’t cost more or take more time.  How do you resolve this dilemma?

Project Management success is determined by delivering both the project (what you promised) and customer/owner/stakeholder satisfaction (what they expected).  Failure at either of these is failure.  Even if you deliver the greatest technical solution imaginable, if the customer is not happy, you are not going to stay around long or get that next job.
Our success as project managers, then, is to get agreement up front for what we’re going to do, do it, and then get acceptance that we did it.  How then do we get agreement on scope up front?  How do we avoid the dilemma described in the opening paragraph?

The Work Breakdown Structure, which I’ve been discussing in the past several posts, is not an academic exercise.  It, along with the Task Dictionary, defines the scope of your project.  A well constructed WBS/ Task Dictionary agreed to at the start of the project by the key stakeholders will greatly reduce the kind of disagreements described above.  That is, the WBS becomes the basis for determining Project Change Management, and without the WBS it is just “I say – They say,” which ultimately leads to project failure.
Agreement on the WBS is more than just sending an email and asking for approval.  Sit down with your stakeholders, walk through each Deliverable and The Activities and The Tasks that comprise each deliverable.  Discuss what is included.  You’ll be amazed at the results.  Many misunderstandings will be cleared up here, early enough to easily resolve them and prevent acrimony later;  they will find that you’ve included activities that they disagree with;  they will identify missing activities;  and, most importantly, they will begin to take ownership of the mutual delivery of the project.

I’ll have more to say about Project Change Management in a future post, but the other essential value of the WBS is that it becomes the foundation for building the project schedule.  In the next series of posts, we’ll discuss what is needed to build a well-formed project schedule.
When was the last time you conducted a WBS walkthrough with your stakeholders?  How did it turn out?

Thursday, July 5, 2012

The Project Manager’s Cycle – Publish the Project Status Report

“Project status this week, in a nutshell, is that we are continuing to stay on schedule, but this is despite your team’s contribution.”  After the initial chit-chat, Srini intentionally opened the status meeting with a statement to get everyone’s attention, especially the Sponsor and Owner Jack.  “Our project team has been working around the delays of returning document reviews and approvals.  We’ve pretty much exhausted the continuing work, though.  As you can see on the status report, there are several deliverables over due for approval and the draft requirements document is held up.  If you think these durations will continue, then I recommend that we extend the time your team is allocated for these activities and extend the time line.”
With this post, we conclude documenting the activities in The Project Manager’s Cycle, the Monitoring and Controlling activities that the project manager performs each reporting cycle for the life of the project.  All of these activities (with the exception of the Client Project Meeting) build each week to the Project Status Report (PSR).  The PSR encapsulates all of the information the Sponsor/Client/Owner and all Stakeholders need into a compact package.
The PSR should document both the current status of the project (in summary) and progress since the last report.  The essential elements of the PSR include an Executive Summary, Accomplishments, Planned Accomplishments (in the next reporting period), Deliverable/Approval Status, Change Request Status, and Issues.  Accomplishments and Planned Accomplishments are reported relative to the plan (project management is the classic example of Management by Objectives).
Note that traffic lights (  Red,  Yellow,  Green) are not in my list of essential elements of the PSR.  I am ambivalent about them.  When used properly they are often valuable, but they are even more often used improperly.  If you use traffic lights, the meaning of each color must be defined clearly and all of the stakeholders reading the PSR must know what each color means.  Further, a single light is really not meaningful.  After all, the ultimate purpose of the lights is to show where external action is needed and one broad status doesn’t provide the specificity needed.  Rather, what I’ve seen that works best are lights representing Schedule, Scope, Budget, Resources, and Closure/Acceptance repeated for each project phase or (preferably) each deliverable.
The PSR is probably the most important document the PM produces and I can’t cover all of the nuances in one post, so expect to see more on other elements of the PSR in the future.
That said, Western PM tradition utilizes an almost universally identical PSR format and content.  For a take on something significantly better and much more visual, check out the A3 Reporting system utilized by Toyota world-wide.  For an explanation of A3 Reporting in the context of the over-arching Toyota manufacturing system, there is Extreme Toyota: Radical Contradictions That Drive Success at the World’s Best Manufacturer (Osono, Shimizu, and Takeuchi, 2008).  There are also several books specific to the A3 report, including Understanding A3 Thinking and The One-Page Project Manager for Execution.  These three links are short blog posts that introduce the A3 Report:  The A3 Problem Solving Way: An Introduction, The ABC’s of A3 Performance Improvement, and The Seven A3 Problem Solving Steps in Detail.  For the best book I’ve ever read for structuring IT project management, there is The Toyota Product Development System: Integrating People, Process, and Technology (Morgan & Liker, 2006).  This also has a good introduction to the A3 Report in the context of the Toyota Tao.
Do you have a project status report best practice to share?  How about a PSR disaster?

The Activity

In my previous post, The WBS Basics, we developed a simple Work Breakdown Structure (WBS).  In previous posts related to this foundations series, I’ve discussed TheTask and Deliverables.  A WBS is, as previously noted, a hierarchical representation of the complete project scope.  (A list of all tasks without any organization structure would be more confusing that beneficial.)

But with a moment of consideration about the hierarchical nature of this representation, we realize that if we just have tasks at the bottom and deliverables at the top, we really haven’t improved the situation meaningfully.  With no hierarchy, a Deliverable with hundreds of tasks would be just as confusing as a project with hundreds of tasks.

Therefore, it’s easy to determine that for large projects, there could be several layers between the Deliverable and the Task, as represented by this diagram with arbitrary names for the intermediate levels.


A work breakdown structure is like an assembly Bill of Materials – it lists all of the components in the final product and shows graphically how they fit together from individual parts (Tasks), through subassemblies (Activities), to the top level assemblies (Deliverables).  And the WBS developed for project management much like the Bill of Materials developed for assembly and they serve much the same purpose.  Complex BoMs with randomly arranged layers are normal.  Likewise, there is nothing wrong with (defective about) a WBS like this and I’ve certainly seen many PMs comfortable with this (un)structure.
 

As already mentioned, large projects have many (thousands of) tasks and the hierarchical structure is needed to organize the work.  The intuitive choice for organizing the work, as a box is examined and decomposed, is to build the structure into progressively more levels, as shown above.  This is evident to most practitioners and quite obvious.

But this blog is for presenting Best Practices and I’m going to explain why an alternative, not necessarily as intuitive, is the Best Practice.  Let’s say you have a project template that you use that has four deliverables and usually takes a couple of months.  Thus, you produce a deliverable every couple of weeks.  Then you get a request for a really BIG version of this same project that will take two years.  The intuitive approach, as discussed, would be to build out detail within each box (for assemblies, what they would call exploding the BoM).  You would then have your familiar project structure with possibly several additional levels.

But do you really want to have only four deliverables over a two year period?  Do you want to “go dark” for six months at a time?  This is not a Best Practice.  All projects need frequent deliverables to get meaningful feedback on the quality of the work.  Consultancy PMs in particular benefit from frequent deliverables so that they can book the revenue.

As more deliverables are added to the WBS, it naturally flattens out so that a PM only needs a limited number of levels.  Gone are the Assemblies, Subassemblies, and Hemi-Demi-Semi-assemblies.  You can even deduce that a WBS with many layers would be a red flag to review the frequency and distribution of the deliverables.

I have run many large projects with only three hierarchies within the project:  Deliverable, Activity, and Task.  Further, unlike the example above that appears to have evolved randomly, a planned, well-structured WBS is the sign of an organized project.

Have you run a project where you didn’t have control over the WBS?  How did it turn out?