Some early comments via e-mails on my post on why Excel is not a PM tool raised the issue that I was being way too hard on IT shops and letting application providers off the hook. The asymmetry was certainly not the intention (at least not consciously).
When approaching an organization seeking process and technology improvement, oftentimes the condition of using Excel is what we in the technology/PM industry conveniently call “workarounds.” Ostensibly these workarounds are temporary measures to address a strategic or intrinsic organizational need that will eventually be addressed by a more cohesive software solution. In all too many cases, however, the workaround turns out to be semi-permanent.
A case in point in basic project management concerns Work Authorizations Documents (WADs) and Baseline Change Requests (BCRs). Throughout entire industries who use the most advanced scheduling applications, resource management applications, and–where necessary–earned value “engines,” the modus operandi to address WADs and BCRs is to either use Excel or to write a custom app in FoxPro or using Access. This is fine as a “workaround” as long as you remember to set up the systems and procedures necessary to keep the logs updated, and then have in place a procedure to update the systems of record appropriately. Needless to say, errors do creep in and in very dynamic environments it is difficult to ensure that these systems are in alignment, and so a labor-intensive feedback system must also be introduced.
This is the type of issue that software technology was designed to solve. Instead, software has fenced off the “hard’ operations so that digitized manual solutions, oftentimes hidden from plain view from the team by the physical technological constraint of the computer (PC, laptop, etc.), are used. This is barely a step above what we did before the introduction of digitization: post the project plan, milestone achievements, and performance on a VIDS/MAF board that surrounded the PM control office, which ensured that every member of the team could see the role and progress of the project. Under that system no one hoarded information, it militated against single points of failure, and ensured that disconnects were immediately addressed since visibility ensured accountability.
In many ways we have lost the ability to recreate the PM control office in digitized form. Part of the reason resides in the 20th century organization of development and production into divisions of labor. In project management, the specialization of disciplines organized themselves around particular functions: estimating and planning, schedule management, cost management, risk management, resource management, logistics, systems engineering, operational requirements, and financial management, among others. Software was developed to address each of these areas with clear lines of demarcation drawn that approximated the points of separation among the disciplines. What the software manufacturers forgot (or never knew) was that the PMO is the organizing entity and it is an interdisciplinary team.
To return to our example: WADs and BCRs; a survey of the leading planning and scheduling applications shows that while their marketing literature addresses baselines and baseline changes (and not all of them address even this basic function), they still do not understand complex project management. There is a difference between resources assigned to a time-phased network schedule and the resources planned against technical achievement related to the work breakdown structure (WBS). Given proper integration they should align. In most cases they do not. This is why most scheduling application manufacturers who claim to measure earned value, do not. Their models assume that the expended resources align with the plan to date, in lieu of volume-based measurement. Further, eventually understanding this concept does not produce a digitized solution, since an understanding of the other specific elements of program control is necessary.
For example, projects are initiated either through internal work authorizations in response to a market need, or based on the requirements of a contract. Depending on the mix of competencies required to perform the work financial elements such as labor rates, overhead, G&A, allowable margin (depending on contract type), etc. will apply–what is euphemistically called “complex rates.” An organization may need to manage multiple rate sets based on the types of efforts undertaken, with a many-to-many relationship between rate sets and projects/subprojects.
Once again, the task of establishing the proper relationships at the appropriate level is necessary. This will then affect the timing of WAD initiation, and will have a direct bearing on the BCR approval process, given that it is heavily influenced by “what-if?” analysis against resource, labor, and financial availability and accountability (a complicated process in itself). Thus the schedule network is not the only element affected, nor the overarching one, given the assessed impact on cost, technical achievement, and qualitative external risk.
These are but two examples of sub-optimization due to deficiencies in project management applications. The response–and in my opinion a lazy one (or one based on the fact that oftentimes software companies know nothing of their customers’ operations)–has been to develop the alternative euphemism for “workaround”: best of breed. Oftentimes this is simply a means of collecting revenue for a function that is missing from the core application. It is the software equivalent of division of labor: each piece of software performs functions relating to specific disciplines and where there are gaps these are filled by niche solutions or Excel. What this approach does not do is meet the requirements of the PMO control office, since it perpetuates application “swim lanes,” with the multidisciplinary requirements of project management relegated to manual interfaces and application data reconciliation. It also pushes–and therefore magnifies–risk at the senior level of the project management team, effectively defeating organizational fail safes designed to reduce risk through, among other methods, delegation of responsibility to technical teams, and project planning and execution constructed around short duration/work-focused activities. It also reduces productivity, information credibility, and unnecessarily increases cost–the exact opposite of the rationale used for investing in software technology.
It is time for this practice to end. Technologies exist today to remove application “swim lanes” and address the multidisciplinary needs of successful project management. Excel isn’t the answer; cross-application data access, proper data integration, and data processing into user-directed intelligence, properly aggregated and distributed based on role and optimum need to know, is.
Life, Project Management, and Everything 