4 keys to successful project management software implementation in big organizations

The Dark Side of Project Management Tools: "It's Not a Light...It's a Train!"

Joe Kolinger

Abstract: Project management tools on the market are numerous and their sophistication is ever-increasing. While they provide many essential functions, advertise great ease of use, and get many project managers "excited", their implementation can easily become a runaway train. To some the reasons for implementation failure may appear obvious. Yet, due to the frequency of failed implementations I have concluded that it may be obvious only to those with painful hindsight. This article addresses four key areas that have repeatedly surfaced in my experience at SBC.

69 Sandy Creek Way – Novato, CA 94947 (415)898-2300 [email protected]

The Dark Side of Project Management Tools: "It's Not a Light...It's a Train!"

"Software costs reached about $140 billion worldwide in 1985. Fewer than 1% of all commercial software projects were completed on time, within budget, and to specifications. Businesses were unable to use 75% of software programs they undertook. It is predicted that by 1995 a modest 20% improvement in productivity could be worth $90 billion annually." (SRI Datalog No. 146, May ‘88)

These figures may be shocking, but coupled with increasing foreign and domestic competition, effective project management moves from the realm of being "a good idea...if we only had the time" to an imperative for survival. To bring urgent help in avoiding such scenarios of doom (and quite possibly the end of civilization as we know it) numerous project management software tools have appeared on the market. These tools run on mainframe or personal computers and address the basic functions of project management: planning, estimating, scheduling, and tracking. Almost all commercial project management software is limited to the functions of scheduling and tracking alone. Few packages, if any, include up-front planning and estimating functions, even though complete plans and viable estimates are essential ingredients for a good schedule. Although scheduling and tracking tools automate the more tedious, calculation-intensive functions of project scheduling, a plan must first be defined in detail. Such a plan should include a well thought-out work breakdown structure (WBS), a detailed list of tasks or activities, the activity work-flow, estimated activity efforts, a responsibility matrix, and a profile of the resources responsible for performing each activity. Next, this plan data is entered into the tool. Then the tool performs a mapping of activities against a calendar to yield a schedule with start and finish dates on each activity. Tracking features such as time line charts and textual reports showing work completed, work remaining, and project resource (personnel) utilization are normally available from such tools. Planning and estimating packages are typically CASE tools that can generate, analyze, and report on project plan data, and are most powerful when applied to projects where a repeatable process or lifecycle for software development has been defined. In some cases they can serve as a "front end feed," exporting plan and estimate data to the scheduling and tracking tools. Many companies have purchased scheduling and tracking tools with the expectation that their use would encourage mature, effective, and articulate project management. What frequently happens is that the tool is not as easy to use as its advertising suggests. In the struggle to make it work, the tool, rather than the project, becomes the focus of attention. Often, after considerable time has been spent in training, practice, and frustration, it ends up as "shelfware."


Having assisted with several wide-scale deployments of project management software tools for Information Systems (IS) project managers I have observed both successful and failed tool implementation. The focus of this article is on the troubled cases, where I have noted four major problem areas which prevented successful tool use. The intent here is not to say that such tools are to be avoided, but to create an awareness of major issues which can hinder their proper use. Success is possible, but it requires a well-defined approach and realistic expectations. If you are considering the acquisition of project management tools, or if your application of these tools doesn't appear to justify the expense, then I offer the following areas for examination:

1) Unrealistic expectations 2) Inadequate preparation and training of staff 3) Difficulty in applying the tool to real-life situations 4) Inability to extract the information necessary to manage the project


1) Unrealistic Expectations - The overall abilities of project management tools are frequently overrated. They won't turn a monkey into a project manager, and often they wind up doing the reverse. Regrettably, tool limitations are rarely recognized until considerable time has been spent learning to use the tool, gathering and loading project data, and trying to develop reports which please both management and the project team members. This struggle continues, of course, while the project is well underway - and slowly, but surely, the schedule slips behind. The problem usually lies with the tool user's insufficient grounding in the disciplines of project management, and a misconception that a tool will make up for this. Also, there are no substitutes for an organization which values and understands the ingredients of successful project management, and has committed itself to a process which encourages it. These necessarily precede the successful introduction of any tool. There are no shortcuts and this should be understood up-front. There are some expectations which tools cannot meet. Managers must realize that no tool can create a project plan by itself; it merely reports on the contents of a plan. The tool does not know what the resources are really doing with their time, and it does not know if the right activities are being performed or if they are being performed in the proper sequence. The tool cannot compensate for the absence of sound project management policies, practices, and standards - neither will it compensate for a project manager's absence! The tool will assist the project manager; it will never manage the project. It will not replace the need for face-to-face communication, regular project meetings; clear goals, roles and responsibilities; taking a risk, making a decision, renegotiating priorities, or a manager's intuition and expertise. It is useless for discerning hidden agendas. Neither is it much help in resolving interpersonal conflicts (it will probably cause a few). Worst of all, it will not lend you money. Their attractive packaging and flashy advertising makes some tools appear as though they were developed in heaven, and now for the first time have been made available to mere mortals. In many cases, packaging and advertising are developed by a separate company, and well in advance of the software tool's completion. As much as one wants - and needs - to believe that a tool can make project life easier, be wary of the market hype. Remember:

A project management tool does not a project manager make. Or, better yet: "A fool with a tool is still a fool!" - Bill Curtis of MCC


2) Inadequate preparation and training of staff - Project management packages have earned a reputation for being a particularly knotty family to deal with, presenting hand-wringing and hair-tearing "excitement" on more than an occasional basis. These tools require proper training and guidance if you want to become productive in short order. In the unlikely event that you have an abundance of time on your hands, you may want to chance it and learn on your own. If your choice of training is done haphazardly, you probably will learn on your own anyway. Unfortunately, selecting suitable training is not a sure-fire matter. Training requirements, whether for an individual or for an entire organization, must be assessed in terms which go beyond the operation of the tool. It is crucial that training address the processes by which projects are to be managed. And this may vary substantially among organizations, companies, and industries. How project progress is evaluated, what project information is gathered, and how this information is used to support decision making, improve quality, manage the project budget, etc., must be included and customized to suit the needs of each unique enterprise. "Off-the-shelf" training which offers a generic tribute to project management theory and practice will simply not suffice. In addition, what may not be obvious is that fundamental concepts must be learned before the tool can be effectively used. A basic understanding of PERT and CPM - foreign to many IS professionals - is essential. PERT (Program Evaluation and Review Technique) and CPM (Critical Path Method) are the basic algorithms in any project management tool, and form the theoretical background necessary for evaluating the tool's input and output. In addition, some knowledge of resource allocation and resource leveling are important. These are powerful algorithms which ensure that personnel are being efficiently utilized on the project schedule. If these are not understood the tool will be misused, and the tool output will be useless. It is not enough to understand the operation of the tool; the underlying concepts must be properly understood in order to successfully operate and apply the tool. Finally, the learning curve for project management packages is commonly quite long and steep. It is important that after training, newly acquired knowledge not be allowed to enter "cold storage." Similar to other tools (or musical instruments), practice - and lots of it - makes perfect. The need for on-the-job practice immediately following the training, however is usually underestimated. Our experience indicates that up to five days of practice or practical use are needed to solidify the skills learned in one day of training. If the fundamentals are not learned in a formal training class this may take even longer.


3) Difficulty in applying the tool to real-life situations - Developing project schedules which match the way IS work is really done is often tricky and awkward. The root of this problem can be traced to insufficient planning. Trying to plan while scheduling will often lead to disaster. Planning is a separate process, and should be done up-front where it can address the reality of true project needs. Otherwise the plan will yield to the politics of deadlines and budgets, resulting in missed deadlines, poor quality, loss of morale, or other miseries. Another problem lies with the use of tools which were not designed to accommodate the unique needs of IS project management. With few exceptions, scheduling and tracking software was originally designed for use within manufacturing, construction and aerospace industries. The work in such industries is easily accommodated by these tools, but sometimes just a peek inside the package tells you that this might not be the right tool for the IS business. Consider the names of activities found in some of the tutorials which come with the software: "plant tulip bulb"; "construct road block"; "pour concrete"; "fabricate specs." When was the last time someone in the IS business fabricated something (other than interesting stories and excuses for missed schedule dates)? This clearly betrays the bias of these tools. The nature of work within construction and manufacturing projects can generally be described as relatively concrete, reasonably predictable, and not terribly sensitive to resource availability. Construction projects can benefit from data gathered in previous similar projects regarding activities, sequence, and estimates. This information is fairly transferable from one project to another. In the IS business the state-of-the-art in terms of standards and task effort data collection is improving, but at present it would be generous to say that the average IS project manager cannot plan and estimate very well. The work flow or sequence of activities changes frequently; the schedule is tremendously sensitive to resource availability, as resources are shared among numerous concurrent activities/projects. Also, the replacement of a resource involves long lead times and learning curves. A carpenter can be replaced with another carpenter, but one programmer cannot always be quickly replaced with another. So the management of the critical path, while important, does not become the focus as much as the management of resources. For some IS projects, isolating the critical path becomes almost meaningless as resource availability (or rather unavailability) causes just about every activity on the project to become critical. This does not mean that the tool is useless, but that greater skill in using its advanced resource management features will be needed. Regrettably, many give up on the tool before this is discovered. Loading the initial project plan into the scheduling and tracking tool is about as easy as the job gets, provided of course that you have access to good planning data. If you don't, then you should back up a step. After all, without comprehensive plans and viable estimates you're just loading in guesswork. And scheduling and tracking tools are GIGO (garbage-in-garbage-out) systems at best. Developing project plans which accurately identify activities, work flow, resources, and deliverables is fundamental to success with the tool and, more importantly, management of the project. For some


projects a senior project manager may have all of this information in his/her head. But for most mortals, lifecycle and planning tools are essential for sound plans. The real challenge begins as the project takes off and people begin reporting their time. Not too much time passes before downstream tasks are being reported as complete before the upstream predecessors have begun. "So, if our estimates haven't changed and your people have completed almost half of the project activities," the boss asks, looking at the schedule, "why does the project completion date keep slipping into the future?" Such questions generate investigation and analysis which on larger projects can become complex and very time consuming. All too often a tool's limitations place demands or restrictions on how work will be defined. It is essential that the tool does not drive the process - unless the tool offers a more viable approach. Beware of changing sound business practices to suit the tool's weaknesses or idiosyncrasies.


4) Inability to extract the information necessary to manage the project "Don't worry," the salesman says, "with our custom reporting facility and full export feature, you can get all the data you need. Just look at these beautiful charts and graphs!" "Looks pretty good. How could we go wrong?" you think. But, one week later, back at the ranch, there's despair brewing as the tool is producing report output that doesn't seem to match the project plan (ie., the tool is showing the project as completing in 2097, even though manual calculations indicate that it's a one-year effort). And this perplexes the dickens out of project managers. So they begin to wonder if there isn't a tool which makes holographic five-color PERT diagrams. Actually, this may not have much to do with the tool. The key question is: what were you expecting? What were your management reporting requirements? These requirements should have been specified prior to finishing the development of the plan. What questions would need answers? What information would be needed to manage the project? Would progress be measured by phase or by deliverable? Would the resources be measured by hours worked on specific deliverables? Would the resources' hours even be tracked? The answers to these questions determine how the project work would be initially broken-down and defined when building the plan. It takes commitment and effort to keep the project schedule updated. Many users become impatient or discouraged with the tedium of updating project plans. Without this commitment the reporting will become useless. Many project managers have plans loaded into a scheduling tool, but few have up-to-date plans. Clear and valid reporting and input requirements, a dedication to keeping the project data current, and a good understanding of the tool's reporting capabilities, will give the project manager convenient access to the necessary project data.



* * * * * * * * * * Conclusion - Project management tools on the market are numerous and their sophistication is ever-increasing. While they provide many essential functions, there is plenty of opportunity to become side-tracked with bells and whistles. The potential for benefit is certainly great for a project manager who understands the issues of project management, who has the skills, and who knows the appropriate place for the tool. An awareness of these issues can help a project manager save precious time, and can help maximize the use of the tools of our trade. This article has focused on four common problem areas associated with the introduction of project management tools. The author recognizes that other significant issues exist (ie.,organizational health, technological maturity of an organization, sponsorship of executive management, availability of the right resources, appropriate tool selection, etc.) which may strongly influence successful project management. About Us Kolinger Associates provides solutions and advice for better estimating and managing large projects. With our help you will …

Spend your money a little differently … and get a much better result.

Also see, “7 Signs You Have a Bad Project Estimate … and What to Do About It”: http://www.kolinger.net/2010/02/03/7-signs-you-have-a-bad-project-estimate-and-what-you-can-do-about-it/ Go to www.kolinger.net for more details or email [email protected]

http://www.kolinger.net/2010/02/03/7-signs-you-have-a-bad-project-estimate-and-what-you-can-do-about-it/

http://www.kolinger.net/2010/02/03/7-signs-you-have-a-bad-project-estimate-and-what-you-can-do-about-it/

http://www.kolinger.net/

mailto:[email protected]