The project manager’s ultimate responsibility is to protect and promote the business for whom he is working. Towards that end, the project manager works diligently to produce the best business results, meeting or exceeding the objectives of the “triple constraints” – scope, time and resources. However, there are a number of instances where the astute project manager will realize his business is on a pathway to failure. These situations need to be addressed and assessed against project objectives or corrected before the business suffers avoidable losses. The initial approach for the effective project manager is to remove the hurdles that impede her project. Sometimes however, that cannot be accomplished easily. In these cases, the project manager needs to take a profoundly opposite role – they need to become a hurdle – a hurdle to impending disaster. This role as a hurdle becomes vital when the organization is unlikely to “back off” the execution of a project even if there is little chance for project success. Some of the more common circumstances that lead to the demise of projects are addressed here. When these surface, it’s “hurdle time” for the courageous project manager!
Projects with pre-defined triple constraints
The trend is very disturbing – a large number of projects come with all of the triple constraints predefined. The project manager is told what will be produced, how long it will take and how much it will cost. Pre-defining the triple constraints is a short sighted sponsor’s approach to “being a strong leader” and it just doesn’t work. How often have you taken your car to the service center and told the mechanics what they will find when they peer under the hood, told them what time they will have your car available for you to pick up, and how much they will charge you for the service? Of course we don’t do this with our cars! Accepting a project of this nature without questioning the sponsor is irresponsible. Projects need to be examined for the credibility of the desired outcomes, imminent risks, and evaluated against the organization’s available skilled resources. Except in cases where there is a very well documented and understood history of analogous projects in the sponsoring organization that validate the predetermined triple constraints, projects will all three triple constraints pre-defined will not succeed.
With the ever increasing demands on senior leaders – be mindful that they too are trying to do more with reduced numbers of resources – the details and challenges that are everyday issues for the project manager don’t always enter the mind of the project sponsor. Tactful and tactical approaches – like asking to conduct a short investigation – can bring these potential issues to light, giving the project manager some “breathing room” to negotiate the expectations for the project. At the very least it provides a means to identify risks and potential response actions to increase the chances of meeting the expectations for the project.
This is an example of the project manager presenting an appropriate “hurdle” to what the organization is asking. There are many examples of these projects however – here are some additional cases.
Projects that change processes, without appropriate business analysis
Another common way to poorly conceive a project is when the deliverables for a project involve changing tools and business processes simultaneously and analysis of the “as-is” and “to-be” business environments are not considered as part of the project scope. Automating a process that is not well defined or implementing new or changed automation without the appropriate examination of the existing and new business processes results in disaster. Examples of this abound, as evidenced by the large number of failed projects in the Enterprise Resource Planning (ERP) space, using extensive product suites such as PeopleSoft ®, SAP®, and J.D. Edwards®. These software suites are quite capable – but they are frequently installed in hopes they will facilitate the improved execution of existing business processes. It doesn’t take long for the users to report that the product doesn’t work. The reality of the situation is this – the software suites do “work,” just not to facilitate the precise business process the users are trying to execute. A significant mismatch exists between the processes the users are accustomed to executing and the processes that are inherent in or implied by the software.
Projects that seek to change both processing tools and the user’s business processes need to contain a number of required initiatives in order to succeed. These initiatives include an analysis of existing business processes – the “as-is” model. Only with a well defined set of current processes will the project manager and her team understand what processes are going to change, where current complexities exist, and areas for improvement – and therefore what needs to be communicated and taught to the user community.
The second major required initiative for these projects is the definition of the “to-be” model – the set of processes that will result from the project deliverables. ERP product suites have an implied set of processes inherent within them. The providers of these software tools seek to support and promote business processes that reflect common practices across a broad swath of industries, as well as focus on “best-practices” to achieve efficiencies across the organization. Inevitably however, the ERP product processes will differ from the processes that are part of your organization’s “as-is” profile. Conscious and well thought out management decisions need to be made to decide: a) if processes in the organization are to be altered to match the processes supported by the tool; b) if the processes inherent in the tool will be changed by customizing the tool to match the business environment or, c) both the tool and the businesses’ processes will be changed to “meet in the middle.”
In many situations the process modeling work effort can be perceived as a waste of time and simply slowing the project down. In reality; performing effective process modeling will enable the project to run more smoothly by identifying problem areas up-front and ensures the overall success that the product that is ultimately delivered to the business will truly meet their needs.
Let’s examine one more project hazard that requires the project manager to be a hurdle…
Projects with unavailable project customers
When the definition and approach derived for a project isn’t the problem, it is often a lack of qualified, knowledgeable business personnel. This issue manifests itself with everything from the “you should know what I want” approach from project customers, to a blatant absence of project customers in project proceedings because they are “too busy.” This causes project managers to try to proceed with a significant handicap. A large portion of the project management community try to “press on” in this situation despite the lack of customer participation, surmising – inaccurately – that the organization will be better off if they at least create “something” for a project deliverable. The actual results are usually catastrophic; skeptical project team members that do not trust the product they are creating, a totally alienated customer that receives a product for which they feel no ownership, and a sponsor with a lack of confidence in the product and project management because of “poor” delivery.
Because these disastrous results are inevitable when knowledgeable business representatives are not part of the project, the only real way to respond in a situation like this is to become the ultimate hurdle and recommend the project be stopped until appropriate business personnel can be leveraged. This recommendation will bring a significant amount of attention to the situation which is exactly what you need to solve the problem!
When a project manager escalates due to lack of business resources, a business representative that doesn’t have the appropriate level of experience will sometimes be assigned to assist the project team. In short, they can’t successfully speak for their peers, or the process area they represent. Moving forward with these partially-knowledgeable individuals is just a nicer looking path to the same terrible conclusion. The project should be stopped until this situation can be rectified.
So, as project managers we are most often looked upon to eliminate hurdles, and drive projects to success. Sometimes however, it is most suitable that we become a “hurdle” instead, and ultimately help the project – and our sponsoring businesses – be successful in the end.