Wednesday, 27 March 2013 08:15

From the Sponsor’s Desk - Tackle Your Project’s Highest Risks First

Written by

Davison FeatureArticle March27In my last post, we looked at how one program manager delivered a major change successfully in spite of the fact the sponsor was not interested and not involved in helping the organization manage a significant corporate initiative. His secret weapon: coercion!

In this post, we’ll look at the steps taken by an HVAC contractor to develop and deliver an innovative offering to its clients and the challenges it faced dealing with a number of unknowns and uncertainties. Unfortunately, it failed to identify and manage the project risks and paid the price, in dollars and credibility.

Thanks to reader M.P. for providing the details on this case.

The Situation

This heating, ventilation and air conditioning (HVAC) contractor delivered custom solutions to commercial and industrial businesses. The contractor had been in business for over 25 years but had experienced a slowdown in work because of the 2008 financial crisis and the resulting economic downturn. The three partners were looking for other opportunities to grow revenues and differentiate themselves in a very competitive market. 

In response to these challenges, they conceived of and designed a configurable, off-the-shelf HVAC solution that could be adapted and tailored to a wide variety of needs to provide the required heating, ventilation, air conditioning, noise abatement and odor control services and meet specific pre-established operating targets. Their target market was in the 1000 square foot to 20,000 square foot range. The advantages for their clients included lower costs, faster installation, known and assured operating costs and demonstrated performance. The anticipated benefits for the company included increased revenue, lower costs and higher profit margins. In addition, because their solution required a long term maintenance agreement to keep the systems running at target specifications, the company would have a more stable revenue stream over the long term. 

The partners had built a prototype to prove the concept and were able to sell one of their existing clients on the new system. The client was opening a new high end restaurant in a largely residential area and was counting on the locals for much of his business. He wanted to provide a quiet and comfortable dining experience while making sure that the noise and smells coming from his eatery didn’t earn the animosity of his neighbours and drive prospective diners away. 

The Goal

The client’s planned opening date for the new restaurant was in nine months. In that time the contractor needed to design, build and install the mechanical systems for the new site. That included the duct work as well as the configuration and placement of fans, sensors and filters. The biggest challenges were the software components: one piece would be used to create the design specifications for the site, the other would monitor and adjust the performance of the system on a real time basis to stay within the agreed upon specs. Initial versions had been developed for use in the prototype but they were crude applications in need of considerable refinement. 

The contractor planned to spend $400,000 on the first implementation including $350,000 for the software development and testing effort. The partners projected that with three more similar sized clients on the books they could start showing a profit on the venture.

Their first client had agreed to pay $100,000 for the system plus $15,000 annually for five years to cover ongoing monitoring and maintenance. The contract with the client included performance penalties of $5,000 per month for late delivery. 

The Project

The partners proceeded to hire a contract project manager to guide the software development effort. The actual design and coding was to be done by a local software development firm with target completion in six months. That would allow three months for the actual physical installation and final testing. The partners planned on using in-house engineering, electrical, sheet metal and welding staff for the remainder of the work. The client insisted that his electricians and plumbers do the actual hook-up on site.

The new project manager proceeded to work with the software development team to refine the specifications for both applications based on the prototype and feedback from the partners and engineering staff. Both applications were re-architected to allow input of the variables rather than embedding the information in code as was done in the prototype. A highly configurable physical model was built with the co-operation of the engineering staff to support ongoing application testing and prove the accuracy of the software’s configurations.

The prototype software had made several key assumptions about the characteristics and performance parameters of the various components including motors, compressors, heaters, fans, filters, sensors, insulation and ductwork. As the testing of the configuration software progressed, it became clear that those assumptions would not deliver the kind of performance needed to satisfy all possible situations. The partners authorized the PM to engage with the component manufacturers and suppliers to identify additional options and associated performance parameters and to include those in the model. 

Of course, bringing in new players takes time and adds complexity and cost, especially in the later stages of a project. In this case, it quadrupled the component inventory and significantly extended the testing time, moving target completion of the software out another three months. Recognizing that the software delay would push off implementation and result in monthly performance penalties, the partners authorized the engineering staff to start installing the HVAC system using an early configuration model.

The Results 

The restaurant opened three months later than planned, an embarrassment to the contractor and the client. The delay was due almost entirely to repeated changes in the HVAC system to meet target specs. The project was $90,000 over budget, $60,000 of that on the software side. The contractor was able to negotiate the performance penalties down, arguing that the client’s trades people were as much of a factor in the delay.

Ultimately, the configuration and monitoring applications were completed. Unfortunately, the configuration tool was never able to generate wholly acceptable specifications without a great deal of manual intervention and the contractor stopped development. The monitoring application was used with the initial client and continues in use today, providing value to clients and additional revenue for the contractor.

How a Great Project Manager Would Have Helped

This was an unfortunate case of enthusiasm for the idea over-riding some fundamental change management and project management principles. The three partners and the PM started out with a blank slate. As a result, they ignored or overlooked some critical decisions that could have changed the project outcome for the better. By focusing the PM on just the software development effort, the three partners lost overall control of the undertaking. 

There was no risk plan in place that attacked the most significant risks right up front. As so often happens, the biggest risks were left to the last where they could do the most damage. There was no thought given to phasing and staging the delivery in manageable, bite-sized pieces. The PM focused exclusively on the software development effort until he belatedly realized he’d also have to engage others outside his team to be successful.

A great PM would have pushed back and insisted that someone be charged with responsibility for the whole project and ensuring all the pieces fit as needed. A great PM would have used any one of a number of standard industry frameworks or their own personal practices to ensure the bases were covered. 

For example, use of Project Pre-Check’s stakeholder model would have helped identify the change agent role gap. It would have also helped identify the component manufacturers and vendors as vital stakeholders early on. Use of the Project Pre-Check Decision Framework would have helped the stakeholders identify relevant Decision Areas that needed to be addressed including extended and new external relationships with the manufacturers and vendors, phasing and staging opportunities and prototyping and piloting options to accelerate delivery and reduce risk. It would have also highlighted the need for a comprehensive risk plan to guide the project through and around the many challenges and a resource plan that addressed the skills needed from the contractor’s staff, the client’s trades personnel, the software developer and the component manufactures and vendors. It could have been a very different and highly successful undertaking! If only!

If you find yourself in a similar situation, remember to consider Project Pre-Check’s three blocks right up front and put these points on your checklist of things to do so you too can be a Great Project Manager.

In the interim, if you have a project experience, either good or bad, past or present, that you’d like to have examined through the Project Pre-Check lens and published in this blog, send me the details and we’ll present it for others to learn from and comment on. Thanks

Don't forget to leave your comments below.

Read 9475 times
Drew Davison

Drew Davison is the owner and principal consultant at Davison Consulting and a former system development executive. He is the developer of Project Pre-Check, an innovative framework for launching projects and guiding successful project delivery, the author of Project Pre-Check - The Stakeholder Practice for Successful Business and Technology Change and Project Pre-Check FastPath - The Project Manager’s Guide to Stakeholder Management. He works with organizations that are undergoing major business and technology change to implement the empowered stakeholder groups critical to project success. Drew can be reached at drew.davison@projectprecheck.com

© ProjectTimes.com 2017

macgregor logo white web