As a teacher and consultant, I am vulnerable to lapsing into a sort of fantasy world. It is too easy to see things as they ought to be—rather than how they really are.
Sitting at my computer, far from the battlefield, I can freely write about the prescribed ways to manage projects, and how to use the very capable software tools that have been developed to support these practices.
The wounds of my own battlefield experience, in the ’60s, ’70s and ’80s, have since healed and the scars are hardly noticeable. I remember the successes more fondly and vividly than the failures. I know what can be accomplished and of the potential for the application of recognized practices and tools.
As a believer of the value of project management practices and software, why shouldn't I continue to pontificate about these things? With clear-cut examples of successful project management, why shouldn't I continue to share these experiences? When I see cases of poor management, why shouldn't I continue to challenge organizations to employ recognized, practical project management practices, and to challenge project management software developers to strive to improve their products to support such practices?
The answer, of course, is that this path should not be abandoned. I shall continue upon my trusty steed with lance and armor, and with faithful Sancho Panza at my side. But Don Quixote I am not! It is important to maintain a real-world objectivity. Therefore, I occasionally venture out into the battlefield, by taking an assignment that requires me to practice what I preach.
It was during the recent execution of such an assignment that I was forced to come face to face with the realities of the battlefield. That is: there are an awful lot of people out there who are not interested in doing “good project management.” It is not just a problem of learning about modern project management. Nor is it a problem of not having enough time to either learn or practice project management. Rather, in these cases, project management gets in the way.
You've seen these people. They can't do a work breakdown structure because the way that they intend to structure the project doesn't match the way that the contract was structured. They can't do a project milestone schedule, because senior management doesn't know what's going on and each contributing organization to the project insists on scheduling independently. They can't produce a basic project schedule, because the task list and contract obligations in the SOW are different than the tasks that are actually to be performed. They can't relate a project staffing plan to the project schedule, because the numbers that the computer generates do not match the contract numbers. And cost management—well that's best left to the accountants.
Thank goodness, we still have many organizations that recognize the value of good project management and the use of PM tools. These organizations are still, even in these lean times, willing to staff a project control office and to have qualified people perform the necessary planning and control functions.
But this is far from being a ubiquitous mode. Today, more and more organizations are trying to do “cheap and dirty” project management. They will only execute project plans when required by their client or their management. Here are some of the rules that apply.
1. Never do more than is absolutely required.
2. If there is a discrepancy between the contract documents and the truth, the former takes precedence.
3. It is not necessary for the project staffing plan to match the schedule.
4. Avoid critical path scheduling at all costs. There is no such thing as an inviolate predecessor.
5. Don't let the computer calculate earned value. The number that it comes up with may not match what we want to tell the customer.
6. Buy one or more copies of project management software (it makes you feel like you are doing project management), but don't have any fully qualified users.
I'm sure that we can come up with another dozen or so rules, but you get the idea. Whether it makes you laugh or cry doesn't really matter. What does matter is that this is a real-world condition, and we need to address how to deal with it.
The specific issue that I want to address here is this: Assuming that the organization described above wishes to produce computer-generated schedules and staffing plans, what characteristics should they look for in their project management software?
Forcing Results
The key to this issue is that such users want to force the results to match their expectations. They are not willing to allow the system to calculate the schedule, or to calculate the staffing requirements based on the assignment of resources to the scheduled work. What this means is that they want to override many of the capabilities found in traditional project management software. They are going to take a tool that was designed to create critical path schedules, based on defined work and relationships, and schedule-based resource plans, and force-feed it to generate predetermined data. In essence, they are using the project management software as a presentation tool, rather than a tool to assist in the planning process.
While this offends the purist in me, I do recognize the need to do such things, and I do recommend the use of such project management software tools to present the data. If you fall into this category, here are some of the things to look for in your software:
1. The single most important feature is interaction. The product must have a real-time scheduler rather than a batch scheduler. That is, you make an entry and you can immediately see the results. Most of the low-end products would fall into this category, while most of the high-end products tend to be batch schedulers (enter all data, then calculate).
2. Associated with support for interaction is a strong undo/redo feature, such as in Scitor's Project Scheduler 6 and Primavera's new SureTrak Project Manager for Windows. With this feature, you can try certain data, look at the results, and back out if desired, without having to go back into the records to delete data. Also, to support this what-if approach, you will want to use a product that allows you to see the results easily, quickly, and clearly.
3. A good reporting capability, with on-screen preview, will help users to see the results of their “planning” to see if it matches expectations. This is especially important when producing project staffing plans, as you will need to do trial and error until you get the desired results.
4. To produce forced schedules, you need to be able to enter the desired task dates rather than using calculated dates. Even if you use the critical path scheduling capability, you will need to force or override the task dates. All products support this override, but ABT's Project Workbench and Microsoft Project look like they were designed to support forced dates as a regular occurrence, rather than an exception.
5. To produce forced staffing plans, you need to be able to enter specific resource hours by time period. This calls for a spreadsheet mode of entering planned resource hours, such as provided by Project Scheduler 6 or Project Workbench. Some of the other products allow you to view resource results in a spreadsheet or table mode, but do not let you enter the data that way. This will not do the trick.
6. Another method of forcing resource loads is via resource spreading curves. This capability is only found in the high-end products, such as Primavera Project Planner (P3) and Welcom's Open Plan.
7. Still another handy capability for manipulating resource loads is the ability to apply a multiplier. Let's say that your program produced a resource loading plan totaling 12,000 hours and you wanted it to show 13,500. Using a global edit function (P3 or Open Plan), or macro written in Visual Basic (Microsoft) or CA-Realizer (Computer Associates) you could apply multipliers or fudge factors to force a result. SureTrak has a “Basic Scripts” function that can be used for global edits. Macro capabilities in Microsoft Project 4.0 or Symantec's Timeline 6.1 also support this function. But be warned—using macro and scripting functions is an advanced skill. Those people trying to avoid dealing with the demands of a project management software product will also probably try to avoid learning to use these advanced features.
8. We have barely touched upon costing and progressing issues, because these facets are often ignored in the subject situations, or are addressed via separate reporting functions. However, if you need to present budget data with your schedules or staffing plans, look for the ability to input budget values at any level of the schedule. That is, we would normally expect to generate budget values at the task level and let the software roll the numbers up to summary levels. In the typical situations addressed in this article, we could expect that the budgets could be “top down,” and would not extend to the lowest level.
Presentation Features
1. If schedule presentation is a key reason for using project management software, you will probably be interested in being able to annotate the project bar chart. SureTrak and P3 provide capabilities for placing custom annotations (text or picture) within the graphic. If a bar chart presentation is all that is needed, you might want to look at Foundation Microsystem's Schedule Express. You won't be able to do any CPM, or resource or cost stuff with this product, but it can produce simple, annotated bar charts with relative ease. Kidasa Software's Milestones, Etc. is similar.
2. Schedule presentation is a primary emphasis of Schedule Publisher (available from Advanced Management Solutions and Lucas Management Systems). Among the special presentation features is a flexible time scale (i.e., weekly and monthly sections on the same plot).
3. If you want to produce a simple schedule for a proposal, you may want to have the time bar read in periods from project start, rather than specific dates. Project Scheduler 6, SureTrak and P3 are among the popular products that offer a time scale by period option.
4. Another thing that I would look for is the ability to look at the schedule or resource data at various levels of detail. You'll want a program that allows easy and flexible summarization on the basis of Work Breakdown Structures, Organizational Breakdown Structures, and Resources, as well as adjustable time frames for aggregating resource data. Almost all of the popular project management software packages support this capability. Perhaps the easiest to use in this regard are Project Scheduler 6, Project Workbench for Windows, SureTrak, and Microsoft Project.
5. For people who have difficulty in reading schedule presentation documents (even bar charts), there is a presentation mode that anyone can understand. That would be a monthly calendar sheet. Microsoft Project and Timeline can print schedules, a month to a page, with the planned tasks shown in a traditional calendar format. The Microsoft Project calendar view can even be used for adjusting or updating the schedule.
Users and Abusers
There can be no doubt that the schedules and resource plans produced by project management software systems offer many advantages. They are usually attractive, and take less labor effort than hand drawing and typing. They are easily modifiable and reproducible. You do not have to start over when changing the plans or creating a new plan on a similar project.
An ancillary benefit from computer-generated plans is that they tend to be more believable than hand-drawn ones. You gain instant respectability. Of course, this offers an opportunity to abuse that trust. I would urge users to avoid generating garbage, as it will eventually be unearthed, and the entire industry will be harmed in the process.
Final Thoughts
My experience in producing forced schedules and staffing plans reinforced a lesson learned decades ago. It would have been much easier to generate a real plan, using the capabilities of the software, than it was to force the software to produce the predetermined (if not quite realistic) story.
We have available a wonderful and orderly process for project planning and control. We clarify our project mission and objectives; develop a project strategy; and build project frameworks, such as work breakdown structures and project milestone schedules. Then, using project management software tools, we develop schedules, resource plans, budgets and presentation formats. Finally, we progress, analyze and report on how we are doing. Once the schedule forcers discover the attraction of this process, it is my hope that they will join the legions of devoted project management practitioners.
Harvey A. Levine, principal, The Project Knowledge Group, Saratoga Springs, New York, has been a practitioner of project management for over 30 years and is a past chairman of PMI.
