THE SETTING
This is not an obituary. Nor is it an obiter dictum on project management. Conceiving a PM methodology nurturing it, and finally giving it birth did provide moments of joy. I wish I could say the child grew up and solved all our problems and we lived happily ever after.
I Truly Wish I Could…
As part of electricity distribution function, our department is involved in business endeavors such as Network Reliability, Quality of Supply, Health and Safety, Information Systems development and support, etc. In expending effort towards meeting customer needs, the department initiates and manages large numbers of small to medium-size “projects.”
Back in October 1989—acting on the Business Plan—our Management decided to implement a “Project Management” facility for our department. Adoption of formal PM methodology and provision of infrastructure in its support were expected to provide us productivity gains and enhance our competitive edge.
Our team of six staff was pulled off normal duties. At the kick-off session, a formal brief was issued. We were to conduct a rigorous analysis of “requirements” relating to implementing a PM facility that everyone could use, and come up with recommendations within twelve weeks.
We did just that. The recommendations were accepted. Monies were spent. Software was located. Training was provided. Structures were implemented in the organisation.
Six months after providing the PM facility (which, by the way, far exceeds the objectives stated in the Business Plan) we now have just a handful of users, and a large number of very worried people.
“The methodology is too tough,” they say. “We're asked to plan eveything, but how can we anticipate what's going to happen, especially i/ we keep changing our minds about everything?,” they ask.
And, another group wants the system/software to do a variety of things such as monitoring staff absence, preparing annual budgets, and then balancing it between project and non-project works, bookkeeping, sending explanatory notes up the ladder on why things aren't moving along as planned, etc.
What had gone wrong? We'd done everything we could. Or had we…?
Numerous meetings, documents almost 6 feet high, telephone calls crisscrossing the globe, faxes chasing faxes, mainframe graphic terminals displaying glorious colors and consuming CPU time like Armageddon was tomorrow, consultants preaching virtue of earned value and performance measurement, panels discussing how to successfully terminate a project the day after it starts, and me, drawing pictures, making notes and explaining the elegance of resource-constrained schedules and extolling the grace and beauty of S-Curves…
Still a handful of users; a room full of skeptics.
Where is the problem, which by solving, we can truly embark on “Project Earth”?
Of course, you want the details. “You've only described the symptoms,” you say “let's hear the facts.”
Well, I'm Glad You Asked.
Using clear, unambiguous and practically-impossible-to-misunderstand words, the project brief said.
- Carry out a rapid requirements analysis.
- Formulate and submit recommendations.
- Do everything necessary to implement them.
- The management is totally committed to PM.
THE TEAM
The team to which the brief was handed had over 70 years of collective experience as professional engineers, a major portion of which related to hands-on project engineering.
The project manager had considerable experience in multiproject coordination, and in understanding organisational needs from a human perspective
The technical manager of the team had both project management and systems analysis experience.
The remaining members came with a wealth of knowledge amassed from successful management of diverse projects in various disciplines.
All members were keen to solve this issue dating to PM facility for this represented an unique challenge.
THE RESULTS
The team quickly identified the major issues relating to acceptance of formal PM techniques in the organisation. This was done through a series of group interviews, questionnaires and personal, one-on-one sessions. The team sifted through the answers and concluded that any solution proposed must address three basic questions:
- How can we define and setup departmental projects with clear objectives, priorities and accountability in terms of product delivery?
- Is there some computer-based application that would aid us in an umber of PM-related areas such as planning, resource modeling, cost-schedule compilation, etc., on a true multiproject basis and, at the same time, help us track progress on live projects?
- How can we retrain ourselves to look at work as “project”-oriented and use some rather powerful techniques such as WBS, CPM, and Earned Values to aid us in optimizing our overall productivity?
The team then set out in search of solutions. From Do-nothing to Create-a-new-world-order, all options were considered. Their impact on the staff, the organisation, the customers, and the environment was visualized.
Figure 1. Project Management Environment in DSD
Costs and risks were identified. So were the benefits. Direct and indirect. Tangible and the intangible. Credible and incredible!
The final recommendation called for:
- Setting up a framework in the organisation to manage all projects in a “formal” way, based on a PM model.
- Providing systems/software that would supplement the above.
- Providing extensive training to all staff in all aspects of formal project management.
The Management complimented the team's performance and said, “Good Show!”
Final approval didn't take long to materialise. This time around though, a “steering committee” was formed to implement these recommendations.
THE MODEL
The framework (model) recommended as above was not easy to implement. Because Project Management used “Resource Optimizing” techniques and because, in the past, “resource” or nonavailability of it, was always the “culprit” in all projects without exception, divisional management began to demand that all work be “projectised.”
“I'd like to know who's gonna cut the grass at Dongra Park grid AB13 on 31 January 1993.” -The Big Boss, Monday morning.
“Gee Whiz, I better not tell them anything ‘cause they might cancel my vacation.” –The Line Manager said to his wife.
Luckily, it was agreed to early enough, “No-Big-Brother!” No PM system should be reduced to this level of absurdity.
Business Management group gave the model a big nod of approval and US freedom to redefine the holy of holies-the “Job No.” That's the code against which our financial management system actually collects costs. By redefining it to represent a project Cost Account or a Work Package, we'd established a classic environment for collecting actual costs and transferring end-of-the-month cumulative totals to any PM application.
THE SOFTWARE
The SEC owned a range of PM software. On the mainframe, Artemis 9000 was available, both as an application development tool, and as a fully-developed PM application. On the PC, software such as MS Project, PM Workbench, Instaplan, Timeline, Qwiknet Professional, etc., were available. So was an in-house PC product called TRACS, developed using Artemis 2000.
The team recommended usage of the mainframe package Artemis Planning 9000 because of its multiproject environment and easy accessibility under TSO, a level of flexibility.
Artemis Planning 9000 was rewritten to meet our unique structural needs and yielded our current product, MupPET, which stands for Multiproject Planning, Evaluation and Tracking environment.
Today MupPET provides a climate for Multiproject Management Resource Management and Centralised Control. MupPET has a unique link to our financial management system, which ensures that summarised and verified actual cost data get added to the appropriate WBS level of each project, without any prompting from the project manager.
THE TRAINING
Primary focus of the training program developed was to contribute to a “cultural” change in the organisation.
Training was provided in two parts. The first part dealt with the principles of project management and why our organisation was embracing formal project management methodology. The three-day program, conducted by a professional training organisation outside the SEC, dealt with a range of topics, from concepts of critical paths to the relevance of earned values and performance measurement. The topics chosen and examples discussed were specially tailored for our organisation, after independent discussions between the Consultant and the project/program Managers. In other words, we would not be talking hypathetical models such as sending a team of astronauts on an intergalactic rescue mission. Nor would we be discussing issues such as perestroika and glasnost after Mikhail Gorbachev.
Final result? On a complex scale of 1 to 10, the participants gave the training program an astonishing 9.2 average, the absolute minimum of any subsection being a 7!
The second part of the training dealt with using the computer system effectively in the project management area. This three-day training was provided by the software vendors and supported by relevant documentation.
Figure 2. MupPET - Retrofitting formal PM in a constantly evolving organization
This part drew mixed reactions. On our scale of 1 to 10, the minimum for any subsection reached a low of 5. Overall rating averaged at 7.6.
IMPLEMENTATION
Due to corporate-level contractual renegotiation, trial implementation of the system was delayed by six weeks. This time was used for preparing in-house user documentation for MupPET.
Finally, the system was launched for trials in September 1990, and full production a month later, together with full system and user documentation and “Hot-Line” support.
CURRENT STATUS
The DSD organisation is going through significant restructuring, and in the six months since MupPET was launched priorities have changed. Due to staff movements and redefinition of functions, there is a sort of brain-drain in the project management area.
In spite of this, MupPET is used in the planning of some 10 of the top 20 projects in the organisation. The others are projects that are already in progress and project managers are reluctant to change over to Mup-PET due to various reasons.
Though staff are aware of the need for planning project work, producing time-phased budgets broken down to measurable units and a host of issues generally associated with “formal” PM methodology, old habits such as resorting to soft cost estimates and retrofitting available manpower to budgets, etc., continue.
Time and time again, project managers keep pointing out that the PM methodology is fine but execution is well nigh impossible because of reasons ranging from the meticulous nature of planning to poor TSO response.
PM SYSTEMS: COMPLEX, JARGONISTIC AND RESTRICTIVE?
Sure, PM is a complex technique. When costs have to be controlled, products have to be delivered and quality has to be maintained in an environment where several people, organisations and government bodies are involved, the project managers need all the assistance they can get in juggling a number of variables.
Project managers do appreciate the need for formal procedures.
Computing systems that support PM process, on the other hand, despite dramatic advances (both in mainframe and PC) still fall short of expectations in a number of areas. The need for selecting and processing data through a multiplicity of menus or trying to navigate through layers of windows, are not necessarily the stuff that a middle-of-the-road, pragmatic project manager can easily come to terms with. Nor should we expect a project manager to take a lap-top to bed while wrestling with complex works coordination issues.
Project managers will swear by the need for work delegation, authorisation and coordination. They'd like their terminals to shoot out the instructions, collate status, schedule meetings, etc., all using the “information” available in the project database.
The Present Genus of Software Does Not Talk Thus.
Instead of allowing flexibility they often impose restrictions. Restrictions on the way processing of data is to be done. Restrictions on the way reports get preesented.
“But our software is open-coded,” argue the software vendors, implying that you can rewrite the code to meet your special needs.
Some of them indeed are. You need some smart “programming” experience to make them work the way you want them and when you want them. Should this be accomplished successfully (assuming of course that the project manager had plenty of time and skills to rewrite the code), you're then told by the vendor, “Your system will be incompatible with our next release due in the third quarter of 199—, which plays a Beethoven's Symphony in C-minor and Ravi Shankar's full rendition of Jaijaivandhi and Luciano Pavarotti and Placido Domingo and…”
SIMPLIFIED PROCEDURES AND TOOLS NEEDED
If the articles in PM NETwork and Project Management Journal are any indication, PM has almost become a “religion.” The fervour is sweeping the country by storm. Consequent build-up of peer pressure on our middle-of-the-road project manager above becomes quite unbearable. Perspectives get distorted. Fear sets in.
You Don't Need a Smart Bomb to Kill a Fly.
Complex projects do need complex procedures and controls. Perhaps small, linear projects, with no more than two or three work packages, spanning up to three months and with dollar-values less than $50,000 may not warrant rigorous control procedures.
As long as project/product delivery is planned, work is meaningfully scheduled, cash flows and some basic performance measures are established, right at the beginning, chances are that we will be one the right track to complete any projects successfully.
If a second tangible factor maybe nominated as pivotal in the implementation of formal PM procedures in any organisation, small or big, you do not need to look past “software.” This is the one that makes it or breaks it. From TRACS to MupPET, this has stood out clearly.
Any large organisation like ours, tends to have one common PM tool made available to all possible users and, by implication, on all projects, be it building a substation, releasing an annual report, marketing anew product, developing a software application, constructing a power station or commissioning an interstate transmission grid. This need for a common software, common control procedure, common estimation tool, this overpowering need for a sort of apolitical socialism, often looses PM more friends and supporters than it makes.
And again, no two software products seem to function in harmony, despite wide claims about “universal compatibility.”
For instance, Financial Management system pays scant respect to the PM system which needs actual cost data for a forecast report. PM system is seldom able to influence ordering via a Materials Management system so that deliveries can be effected based on a schedule date. Despite voraciously consuming data relating to staff movements, leave, pay status, etc., the Staff Record system hardly makes a meaningful contribution when the PM system wants availability profile for a specific skill.
And often, to make matters worse, each of the above, by design or accident, work under differing environments in the mainframe. Expecting them to work in harmony if one of them, say, the PM system, lives in PC, is quite simply out of the question.
So, have we all been taken for a ride? Didn't someone say, marketing is not giving them what they want but making them want what we want them to want?
WE CAN DO SOMETHING ABOUT THIS
Instead of simply specifying codes of conduct or ethics in the PM profession and leaving the practitioners and protagonists to fend for themselves, there is an overwhelming need to bring PM software to some predefined level of acceptability and intelligence.
This intelligence, of course, is not to tell the project manager how to do this job, but in assisting him by taking much of the guesswork out, minimizing repetitious processing, eliminating meaningless error messages, etc.
Tastefully done screen layouts (Bill Galitz's definitions of complexity and density need rewriting), quick-search reference lists, “where-am-I-now” boxes, “what-next” indicators, drill-down reporting, etc., must become the standards.
A Sidchrome spanner set is well-liked and used without fear, even by rank amateurs, because of its, yes, predictability, consistency and the solid-steel feel. This sort of earthiness is totally lacking in the present breed of PM software packages, which still look, feel, and work like products best suited for Martians.
EPILOGUE
Project Management methodology certainly leads to professionalism in accomplishment. Perhaps, education in its principles and practices should not be left simply to the universities offering degrees in Management, but spread even more widely—to accounting, to medicine, to sociology, to politics, and to economics. And, the skills must be provided via other sources such as the centres that offer trade-related training. There also must exist a mechanism for acknowledging this education.
Project Management can only benefit by making the software smarter, instead of just flashier. The term user-friendly must be formally equated to the adage, “friend in need is a friend indeed.” Project planners, coordinators and managers are always in need of quality information and suggestions about how best to “get on with it” in every project. The PM fraternity should develop and constantly upgrade a set of criteria relating to the design, layout, and intelligence level of any software that claims affiliation to the PM process.
If this means telling the software industry to buckle down and give us what we want, so be it.
And finally, a few thoughts on our attempt to establish a PM culture in DSD. Perhaps, more time is needed for assimilating the philosophy. Perhaps, the timing for its introduction was wrong. Perhaps, the project managers are shell-shocked by the totality of the PM approach and the supporting computing system.
To date, no project manager who has tested the water has come away disappointed.
Total acceptance of the philosophy the methodology and the tool may not be far away, after all.
Kal Balachandran is responsible for the development and implementation of the PM facility in the Distribution Services Department of the State Electricity Commission of Victoria, Australia. He has a B. SC. in mathematics, a B.E. in electrical engineering, and a Post-Grad Diploma in computer management. He is a member of the Institution of Engineers, Australia, and now, PMI. Kal has nearly 20 years of association with electricity instrumentalities in India, the Middle East and Australia, and is actively involved in furthering PM education, system support, external consultancy.