The woes of planning software…recognising key pitfalls
For many years we have made use of planning application software on the assumption that it must be good and it must inevitably help us...but does it? What about the following (genuine) concerns?
It’s a fundamental challenge for project planning software to provide sufficient visibility of the schedule. No screen (not even iMac size screens) can provide enough so that it can be viewed easily. How many people have free and easy access (even at work) to A1 plotters; as well as the physical space and time required to stick the various plots together? And even if you have all of the above, who is skilled enough to plot them correctly (I certainly find it really tricky) and how much does it cost?
Resource and working calendar functionality is available and reflects their many and varied complexities. However these views are rarely presented at the top level: this presents the problem of maintenance (both target and actuals) - not insurmountable but incredibly arduous, time-consuming and often, sadly, retrospective.
In particular, "hammock tasks1" are difficult to plan in a precise and timely manner; let alone retrospectively capture the actuals.
Gantt chart creation is all too easy in much planning software - so how can that be bad news? The temptation to start by creating a Gantt chart simply because it is possible is great. So great, in fact, that they can be generated by almost anybody (alone) without reference to the essential gathering of the project team to create the work breakdown structure; and the veracity and integrity of the Gantt chart is entirely dependent on the quality of the input data (and delivering against it, based on the singularity of purpose as a cohesive team).
Equally the (truly or partially) uninitiated can tend to believe that planning is a simple exercise capable of being completed quickly and with little knowledge or understanding. Terms such as duration, effort, slack, float, EV milestone type can look harmless enough but, for the uninitiated, can leave an accident waiting to happen in the middle of their plan.
Using planning software correctly is complex. A new breed of resource, Project Planners (usually “Software Jockeys”) has emerged that requires intensive software application training that is necessary to make use of the functionality required to best reflect the reality of a project in its plan. The resulting problems then stem from planners not fully understanding what the project manager understands and from the project manager not being able to use the software themselves.
Functionality versus cost
No planning software that I have yet discovered has sufficient planning aids to truly reflect the planning process. Even the generation of work breakdown structures or dependency networks are tedious and time-consuming. Risk management (the reality that turns a ‘happy-day plan’ into a real one) does not yet appear to have made its presence felt within planning applications. Though risk and opportunity databases exist within other applications, the link to such requisite functionality such as Monte Carlo simulations, when used in planning, has not yet arrived.
Cost versus functionality
Simplistic planning software tends to be relatively easy to start to use; and its cost reasonable. However it is constrained by its inability to truly reflect the real complexity of planning a project. In order to better reflect missing functionality, other software applications are required to make up the shortfall (requiring further cost and skill-sets).
By contrast heavyweight project planning software tends to be very difficult to use, can reflect a much greater level of project reality though its costs are commensurately high both initially and on an ongoing basis.
Cost versus cost
Reconciliation of duplicated systems has never been an easy task. And for all project planning software applications there is usually an automated batch or manual batch link to the finance systems of parent organisations making real-time accounting almost impossible (and that is always assuming effort-data collected is complete, timely and correct).
The mythical man-month
All planning software I have encountered does not (and probably cannot ever) take into account the concept of the mythical man-month. A one-person, 20 day effort task when split between four people (according to the software) takes five days. Even if Weinberg’s rules were applied, the reality depends on the specific availability and skills of the individual resources available.
Project data quality
The over-complexity of functionality can easily put-off the trained user, let alone the untrained one. Consequently where individual project team members are required to enter data directly, the chances of that data actually reflecting reality is inversely proportional to the complexity of the software.
Even when skilled user(s) perform regular and frequent updates, the level of effort required to capture and enter precise and timely data that truly reflect a top-quality granular plan is (currently) very significant. The question of whether it is worth retrospectively capturing such quantities of information remains a matter for conjecture.
Furthermore when progress is captured there can be a tendency to make use of the calculations within the software to generate information of highly dubious quality such as ‘Task A is 43.5% complete.’
The reality of planning is that we can only plan a relatively short distance into the future with any degree of certainty. Thereafter we are increasingly at the mercy of risk, opportunity and uncertainty. Consequently the best plans make use of planning horizons (rolling wave planning) where our view of the project end-date becomes increasingly precise over time. Sadly planning software takes no account of the necessary lack of precision; referring instead to its innate algorithms to provide a (relatively) meaningless, but nevertheless specific, end-date. And isn’t that what we were trying to achieve at the outset?
So how do we plan in reality; what software should we use (if any); and how do we ensure we don't fall into these traps?
1.Hammock task - A task that is typically dependent upon a duration or longevity rather than another task or activity - a standard example is that of project management itself.
Article reprinted in part with copyright thanks to the International Journal for Web Portals for provision of extracts from the original publication.