Good Project Plan Schedules

February 12, 2010 — Bruce McGraw

I had a great conversation this week about one of my earlier posts on creating effective and predictive project schedules.  It appears this subject is one of the common topics used in the maturity models being utilized these days.  So I thought I would give another perspective on creating a good project schedule.

Project schedules are essential tools to manage a project effectively – and when constructed correctly they also provide a predictive view of that schedule. Creating a schedule requires the PM to breakdown tasks into manageable parts, establish relationships among tasks, ensure that deadlines can be met, and assign sufficient resources to tasks. Here are some guidelines about project plan schedules from authoritative project management sources.

According to the Project Management Institute (PMI) in the accepted Body of Knowledge for Project management (PMBOK)

Project plan development uses the outputs of the other planning processes, including strategic planning, to create a consistent, coherent document that can be used to guide both project execution and project control. This process is almost always iterated several times. (PMBOK 4.1.3, pg. 44)

The PMBOK further states:

The project plan is a document or collection of documents that should be expected to change over time as more information becomes available about the project. (IBID)


Also, according to the Software Engineering Institute’s (SEI) Capability Maturity Model® Integration (CMMI), Version 1.1, Project Management is a key part of the maturity process and has two key areas for project plans considered areas for achieving the higher levels of maturity: 

  • Project Planning – Goal 1: Establishing Estimates, Goal 2: Developing a project plan.
  • Project Monitoring and Control – Goal 1: Monitoring the Project against Plan

To create a Project Plan schedule that meets all of the standards of a mature project schedule, both as defined in the PMBOK, the CMMI v1.1, and as widely accepted by Professional, certified project managers, should contain at a minimum these 10 items:

  1. Sufficient level of detail (Work breakdown and task sizes)
  2. Defined resources (Named)
  3. A complete network of dependencies (Adequate hard logic)
  4. Specific assignments (Resources against tasks)
  5. Sufficient use of milestones (Includes all Deliverables)
  6. Plan baselines (A static copy of the “plan” against which measures can be taken)
  7. Few constraints on tasks (Constraints are fixed and not predictive – like “Must finish on”)
  8. Actual work being recorded in the plans ( Actual work done on a period by period basis)
  9. Accurate metrics being calculated (Earned Value)
  10. Integration of all project schedules to provide a dynamic forecast and predictive outcome of impacts (“Workplans” or tasks for each team which form the complete schedule)

SEI summarized the use of project plans as:
“A project’s documented plan is the basis for monitoring activities, communicating status, and taking corrective action. Progress is primarily determined by comparing actual work product and task attributes, effort, cost, and schedule to the plan at prescribed milestones or control levels within the project schedule or work breakdown structure. Appropriate visibility enables timely corrective action to be taken when performance deviates significantly from the plan. A deviation is significant if, when left unresolved, it precludes the project from meeting its objectives.”  (CMMI V1.1, pg 219)

One other bit of advice about schedules based on my observations and experience:

A dangerous time in the life of a project is in the middle of the schedule. After the excitement of beginning the project and before the end of project—everything has to be done by when?—there is the sometimes abandoned middle. In the middle of a complex project execution, it is easy to assume that “there is plenty of time left”. One forgets the logic and experience used to build the original schedule.  Remember that a project schedule is not a “wall chart” to be placed on the wall and admired!

Bad idea! Bad practice!

Project managers need the discipline to monitor schedule and plan compliance every week. During project execution, project schedules should be monitored by actual work recorded against the plan.  This means tracking time against tasks.  This allows metrics to be used in the project processes necessary on large projects.  Using staff estimates of percentage complete rather than actual work performed and estimates to complete, is not an accurate method of monitoring progress on a large, multi-project program.  Additionally, without documented, supportable statistics, managers have no credible evidence to support resource demands during the execution of the project.

Following these basic principles gives you a better than average chance that your project schedule is a useful, predictive schedule and not just a static wall chart.

Posted in Best Practice, management, schedule. Tags: , , . 2 Comments »

What to do when everyone leaves town for the Holiday

November 27, 2009 — Bruce McGraw

There are disruptive technologies that completely throw businesses off track and then there are holidays that can be disruptive to project management. The time from Thanksgiving through New Years is a disruptive time when almost all workers will want time off to be with their families. In my experience, it is also a time when clients have a major must-do before the end of the year and government organizations release RFPs with proposals due the first week in January!

This collision of personal schedules and corporate need creates many project management challenges. Now since you are a seasoned project manager (ha! ha!), I know that you have accounted in your schedule for the planned time-off of your team. However, what is a fair and effective way to handle these unplanned, but have to do, tasks?

First, find out if you have any carrots. Talk with HR and senior management about any options you have to offer comp time, over-time, or personal days off after the rush is over.  Or ask if bonus money is available for having staff not take time off and getting the project done.  You do not have to offer these upfront in the discussion with your team; you just need to know what you can do.

Confirm with the client or management about the new project or must-do. Is there room for negotiation on the schedule? When they said end-of-the year, is it possible that the real deadline is early January rather than December 31? Hard though it may be to believe, sometimes customers exaggerate their due date requirement hoping that you can get close enough to meet the real deadline. If the change is the result of a government RFP, there is usually no negotiating — but I have actually talked to a contracts officer who changed the due date by a week when they were convinced that the holidays were a poor time to make contractors work.

Next, meet with the team, tell them the situation, and explain what is at stake for the company. If you make the team part of the solution planning rather than the problem, you may be amazed at their willingness to pitch in to accomplish the tasks. Look for creative ways to get the job done including sharing hours, work-from-home, and even contracting out small pieces of the work—although with little planning time available this option is unlikely to really help and may cost you more time and effort than it is worth.

If you still need resources to get the job done, meet individually with the key players and see what compromises you can negotiate. This is where the carrots come in.

As a last resort, make assignments and require compliance—the stick part of “carrot and stick” management. Be scrupulously fair here!! Do not play favorites. Have a valid, programmatic reason that “John” has to work through the holidays and “Mary” does not. To the extent possible, you can consider unique individual circumstances as secondary criteria to fulfill project needs. This is fraught with potential problems however, so tread very carefully.

Do not ask your staff or employees to make sacrifices that you are unwilling to make yourself. Long after the project is put to bed or the proposal submitted, workers remember that they worked over the holidays and you were nowhere to be seen.

Meanwhile, enjoy your holidays with friends and family and hope that this end-of-year brings no surprises!

Happy Thanksgiving!

Posted in General Project Management, management, schedule. Tags: , , , , , , , . Leave a Comment »

Why identifying software project schedule risks is essential

April 3, 2009 — Bruce McGraw

Developing the schedule for a software project, especially one that is complex, may seem like a task equivalent to predicting when the stock market has reached bottom. That’s one of the best reasons I know for using predictive scheduling with frequent status monitoring and dependencies built in. But, I digress. Let’s say you are relatively new to the PM biz and you have been tasked with developing a software project schedule from scratch. How do you protect yourself, your team, and your organization from the risks inherent in this speculative venture?

In the best of all worlds, you will have an organizational history of developing similar software or solutions, a performance track record for the team members, and lessons learned from other projects. If any of this information is available, it gives you a solid foundation to begin identifying your project schedule risks and defending your estimates. Frequently, however, there is no good historical information to give you a leg up.  Your predecessor did not keep records or the organization didn’t value saving the history.  So you look at number of modules, estimated function points or how many lines of code need to be written, tested, and integrated. Then, you consider what potential risks must you account for in the schedule?  This is a key item for the project manager, because these are the things that will derail the project or cause all of the estimates to be woefully wrong.

What are some real world events that create schedule risks?
This list is not comprehensive and all of these will not happen on all projects. However, some of these events are likely to happen at some time during your project execution.  Therefore you should accommodate them in your risk management plan. (You do have a risk management plan, right?)

  • Coming up to speed on the customer’s problem so the solution fits their operating environment and expectations (Sometimes known as startup time risk)
  • Time required to learn and develop proficiency in new software tools, languages, hardware, or testing techniques (Also known as learning curve risk)
  • Delays in receiving hardware or software—“The memory board must be lost in the mail”; “Our shipping clerk is on maternity leave.”; “We can’t find your order.”; “Our computer system is down.” (Also known as the Murphy law)
  • Loss of a key team member
  • Finding and training new team member
  • Your partners are late delivering their pieces of the project
  • Disruptive team member
  • Shaking the bird cage—corporate reorganization, moving offices, acquiring a new company or being acquired (Also known as the Annual Corporate event)
  • Interruptions from other critical, but not project related, tasks (One example is the holiday and vacation time in December)

Here is a bit of wisdom about scheduling and risk from the Herding Cats blog (“The Five Easy Pieces”)

  1. Hope is not a strategy
  2. All point estimates are wrong 
  3. Without integrating Cost, Schedule and Technical Performance you’re driving in the rear view mirror
  4. Without a model for risk management, you’re driving in the dark with the headlights turn off
  5. Risk Communication is everything

So, if you are now sufficiently worried, how should you identify and manage software development schedule risks?

Brainstorm. As a new project manager, you may not be comfortable trying to identify all the schedule risks on your project. So, pull your key team members together for a brainstorming session. Create what-if scenarios. Talk about what can go wrong. Develop a plan to deal with these risks.

Seek out training. Make sure all members of your team are up to speed on the software tools and operating environment. Work with HR or senior management to offer classes or consultation to improve developer’s skills before you have to rely on them to produce within schedule constraints.

Do your homework. The Project Management Institute offers A Guide to Project Management Body of Knowledge (PMBOK for short) for about $50 (less for members) covering all aspects of program management including risk management strategies. Or, you can get an extension of PMBOK from the Department of Defense  as a PDF download. You want to check out Chapter 11.   There are also good blog posts full of tips on the web like Randy McGowan’s post at ProjectSmart.

Keep communication lines open. Not wanting to hear bad news is a trait we all share. But, as the project manager, you need to know the risks your project faces and you want to know when someone on your team is concerned about achieving the planned schedule. Also, your senior managers do not like surprises. Keep them informed of your potential risks and always have a plan to deal with it, because they will ask.

I feel strongly that it doesn’t take fancy tools and teams of people to manage risks—it just requires some forethought and planning to address risk as a part of any project schedule.  Some of you might smile and call this “common sense.”

What do you think?  Leave a comment with ideas you have on managing schedule risk.

 

Posted in Best Practice, General Project Management, schedule. Tags: , , . 2 Comments »
« Older posts
Follow

Get every new post delivered to your Inbox.

Join 393 other followers