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

Los 33 – The Chilean Miner Rescue

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

Aronson, Marc.  Trapped: How the world rescued 33 miners from 2,000 feet below the Chileandesert.  New York: Atheneum, 2011.

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

Toro, Manuel Pino.  Buried Alive: The true story of the Chilean mining disaster and theextraordinary rescue at Camp Hope.  New York: Palgrave Macmillan, 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.

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?

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?

The WBS Basics

In the WBS, use nouns for deliverables and work packages;  use verbs to name tasks.

-          Danu M. Kothari, Managing Successful IT Projects with the basic “Tools of the Trade,” PMI ISSIG Webinar, July 20, 2006

I have talked about TheTask and Deliverables.  We now have the background to drill into the Work Breakdown Structure (WBS).  The WBS is a “deliverable- oriented hierarchical decomposition of the work to be executed by the project team to accomplish the project objectives and create the required deliverables.  It organizes and defines the total scope of the project.”  (PMBoK v4, p452).  Other than being a circular definition, this is consistent with what I said in “Deliverables as Revenue Agents.”  The stars of this definition are “hierarchical” and “deliverables.”   “Decomposition” and “scope” are supporting cast members.

Since Deliverables define the total scope, the structure starts like this:

Project WBS Example

·         Deliverable 1

·         Deliverable 2

·         Deliverable 3

We now have a decomposition of the total scope for a three deliverable project.  Is this a WBS?  No, the work (each Deliverable) has to be decomposed to the lowest level of work.  As I described in The Task, that level of decomposition is the task.  A well-formed task has one owner and one work product.  We can now show our example project structure as:

Project WBS Example

·         Deliverable 1

o   D1 Task 1

o   D1 Task 2

·         Deliverable 2

o   D2 Task 1

·         Deliverable 3

o   D3 Task 1

o   D3 Task n

This, in fact, is a simple well-formed WBS.  It has a hierarchical structure, is decomposed to the individual task, all tasks are contained within deliverables, and the deliverables (and tasks) define the total project scope.

In my next post, we’ll build on this foundation to explore variations on the basic WBS structure.

Are you ready for more advanced WBS concepts?

Topcoder.com

A future history is a postulated history of the future and is used by authors in the subgenre of speculative fiction (or science fiction) to construct a common background for fiction. Sometimes the author publishes a timeline of events in the history, while other times the reader can reconstruct the order of the stories from information provided therein.
                                                                           From Wikpedia (retrieved 11/09/2011)

I plan to someday post on the Future History of project management.  In the meantime, we might be able to catch a glimpse of what the future holds by looking at one of the more innovative approaches to project delivery that I’ve seen.

I learned about Topcoder.com from an article in Harvard Business Review (“The Age of Hyperspecialization,” Thomas W. Malone, Robert J. Laubacher, and Tammy Johns, July-August 2011, vol 89, pp 56-65).  I apologize to the people of Topcoder.com in advance that my description will certainly not do their service justice.  In a nutshell, if you want a software solution you contract with them.  The solution is presented as a contest (or series of contests) and qualified contestants compete to deliver your solution.  Further, the contest is decomposed into a standard Software Development Lifecycle (SDLC):  Ideas, Planning, Prototypes, Build, Testing, Problems/Problems/Problems, and Deployment.

Project Management is superfluous in their context.  Think about what we Project Managers do:  plan, estimate, monitor & control, communicate, eliminate blockages, herd cats.  Topcoder.com’s methodology and tools eliminate the need for all of these.  On traditional projects, PMs are necessary to assure a meaningful methodology is used and that resources stay focused on their responsibilities.  PMs aren’t necessary when the development methodology is enforced and practiced by all practitioners and where the resources are already fully engaged and motivated (or they lose the competition).  The methodology itself and all the participants enforce the methodology.

Some will respond to this commentary that what Topcoder is doing is different, it’s not project management, and it won’t displace us (i.e., it’s not a competitive threat).  I refer these skeptics to “In Praise of Dissimilarity” (Michael Gibbert and Martin Hoegl, MIT Sloan Management Review, Summer 2011, Vol 52 No. 4, pp 20-22).  Some of the biggest competitive threats originate from where we’re not expecting them.

What do you see bulldozing the project management profession?