Author: 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 [email protected].

From the Sponsor’s Desk – Temper CEO Passion with Discipline, and Stakeholders

Written by Drew Davison on June 12, 2013. Posted in Articles. 2 Comments on From the Sponsor’s Desk – Temper CEO Passion with Discipline, and Stakeholders

In my last post, we looked at how two sponsors and their stakeholder team took a risky but potentially lucrative undertaking from inception to profitable conclusion by focusing on incremental value and delivering one step at a time.

Davison FeatureArticle June12 In this post, we’ll look at the damage a CEO inflicted on his organization when he failed to fully assess a vendor’s claims and refused to listen to and act on the facts when the purchased solution failed to deliver to expectations.

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

The Situation

This mid-sized general insurance company supported its core personal and commercial insurance lines on decades old mainframe applications that had been modified and added to over the years to the point where they were costly to operate, difficult to change and slow to respond to new opportunities.

The CEO of the insurance firm had a friend and former colleague who had recently joined a major software development and outsourcing firm in a senior capacity. The friend started to pitch his company’s new general insurance system. The pitch included the fact that the system was written in the latest, object oriented language and ran on open source software. The friend suggested the new system would reduce the insurance company’s ongoing operating costs, improve their ability to implement changes quickly and correctly and reduce the cost of those changes dramatically.

The CEO was swayed by the arguments and brought in the CIO and the VP’s of the two product lines to hear his friend’s pitch. The CIO saw the proposed solution as a way to get out of the legacy applications’ limitations and be able to offer shiny new technology to retain and attract new staff. The product lines VP’s saw the proposed solution as a way to increase operating profits. They all agreed it sounded great and so collaborated to recommend the project to the company’s Board. The Board approved the project.

The Goal

The proposal approved by the board positioned the vendor’s system as a turnkey solution. All required functionality would be delivered by the vendor. The insurance company was responsible for building interfaces to other corporate applications including finance, management information, human resources, etc. The proposal included net annual savings of $2 million, an estimated cost of $5 million and a project timeframe of 48 months from inception to full benefit realization for both product lines.

The benefits would be realized from reduced hardware and operating software costs. A number of intangible benefits were identified but not quantified including faster implementation of changes, improved software quality and fewer operating problems resulting in greater productivity for administrative and operations support staff.

The Project

The CIO assigned a senior project manager to the project. The assigned PM had years of experience with the existing applications, knew the business and the key players and had reasonable success in the past although not on anything this large. The CIO expected to fill that experience gap by assigning experienced staff from the software company’s pool of PM’s.

The CIO also formed a steering committee that included himself, the two product line VP’s, the Director of Computer Operations and the head of Internal Audit. The steering committee was to meet monthly.

The assigned PM proceeded to line up staff from the two product lines to help define process requirements and test the new functionality as it was delivered. He brought a seasoned programmer analyst on board to work with the business staff and bridge to the vendor’s staff. The PM’s plan was to set up a test bed with the vendor’s software and have the business staff review functionality on a process by process basis. Gaps and differences in functional requirements would be documented and returned to the vendor to be addressed.

To get the test bed up and running, the PM approached the Director, Computer Operations to acquire and install the new hardware and operating system software and services. The PM’s request was met with total surprise. The Director claimed he didn’t have the budget, the staff or the space. It wasn’t on his priority list! A hastily called meeting with the CIO got the Director on side, reluctantly, secured the capital and expense funding, confirmed the priority and resolved the space issue.

Unfortunately, the director had little experience and minimal contacts in the open source technology space so an urgent appeal from the CIO to the application vendor yielded the necessary contacts to get the infrastructure ball rolling. However, it took three months for the necessary equipment and software to be delivered, installed, configured and made operational and to contract with the vendor for the staff with the required skills and experience.

Without the test bed to assess the functionality of the software, the PM turned to the vendor for application documentation the business staff could use to start the assessment. It took six weeks from the date of the request for an envelope to arrive. An envelope! The documentation consisted of a twenty-two page marketing brochure covering all the features, functions and capabilities the software would have. Would have! Further pushing and prodding by the PM revealed the startling truth – the system was still early in its development cycle and the core functionality for the personal line wouldn’t be finished for two years. There were no plans in place for the commercial insurance components but the vendor insisted that the plans were being worked on.

It went downhill from there!

The Results

Instead of pulling the plug then and there, the CEO insisted that the project continue. He justified the continuation on the basis that they would have complete freedom to customize the application going forward. That was a very costly decision!

The first leg of the personal lines application – auto coverage – was completed for the first state four years after the project started. The last state was finally implemented four years after that.
The home insurance coverage component is being worked on eight years later but still not done.
The commercial lines functionality will probably be dropped altogether.
The organization is now on its third CIO and fifth project manager. The original CEO is still calling the shots.
Total costs to date exceed $20 million and operating costs have not only not been reduced as planned, they have grown by roughly $5 million annually to support both the new and old applications and infrastructure.

How Great Stakeholders Would Have Helped

This was a CCoCC (classic case of creeping commitment). The CEO bought a “pig in a poke”! It’s hard to imagine this kind of fiasco happening in this day and age it was so poorly conceived, so badly structured and so terribly managed. When you’re committing millions of dollars of your organization’s scarce capital to a project, you need more than an old friend’s word that things will be wonderful.

There were three factors that caused this failure:

No Stakeholders

The Line VP’s, CIO and Director, Operations had no skin in the game. The CEO called the shots. The other participants had no idea what their roles and responsibilities were. The vendor wasn’t represented in the steering committee, nor were the hardware and software vendors. And where was the Board oversight?
Had the other participants felt some responsibility for the decisions and outcomes, there would have been push back. The Line VP’s would have seen their anticipated growth in profits turning into a black hole. The CIO and Director, Operations would have recognized the challenges from the new infrastructure and the incremental risks to their organizations. The application vendor would have understood the threat to its market credibility and future profits. Unfortunately, the CEO was left to his own devices, to tilt at windmills.
No Measure of Worth

There was absolutely no boundary on expenses, no understanding of how much the organization could afford to spend. There were no formal gates or checkpoints where progress and risks could be assessed and go/no go decisions made. The contract with the vendor was as airtight as a leaky ship. And there was no mutual buy-in to an upper limit on the contract.
Finally, continuing in spite of the setbacks was the order of the day. “We’ve invested too much to cancel now” was the ongoing mantra. What really mattered was not what had been spent. That was water under the bridge. What counted was whether this was a good investment looking forward. It wasn’t!
No Discipline

The normal project disciplines were almost completely absent because of how the venture was positioned – bring in some new application software and move the business over to it.
- There was no due diligence on the offering. There was no RFP/RFQ process to consider alternatives. There was no checking of customer references. Of course, there were no other customers. They were the first.
- There was no allocation for building the new infrastructure and for the staffing and training that would be required. There was no planning or architecture to guide the building and operation of the new hardware, software, services and utilities and to manage the new relationships.
- There was no quality plan. No nonfunctional requirements targets. There was no change control process, no risk plan and no formal issue management mechanism.

In short, this was an outrageous, costly, seat-of-the-pants undertaking that should have been stopped before it even started. Isn’t hindsight wonderful?

If you find yourself in a similar situation, and I hope you never do, put these points on your checklist of things to do so you can be a Great Leader. And remember, look at Project Pre-Check’s three building blocks right up front so you don’t overlook the key success factors.

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.

From the Sponsor’s Desk – Focus on Value, Not Budget

Written by Drew Davison on May 22, 2013. Posted in Articles. 2 Comments on From the Sponsor’s Desk – Focus on Value, Not Budget

davison FeatureArticle May22 In my last post, we looked at how one IT organization responded to corporate pressure to deliver more, faster and at less cost by transforming its organization using high performance team principles.

In this post, we’ll see how two sponsors and their stakeholder team took a risky but potentially lucrative undertaking from inception to profitable conclusion by focusing on incremental value and delivering one step at a time.

Thanks to reader B.F. for providing the details on this case.

The Situation

This large, country-wide retail enterprise was experiencing continuing challenges ensuring that their retail locations had adequate supplies to meet the demand from clients trying to purchase products featured in their many sales flyers and catalogues. Too often, stores were caught with inadequate inventory which left customers frustrated and hurt staff productivity with frequent trips to the store room to search for the requested products.

The newly arrived VP of Marketing was tormented by the lack of control over the full promotion cycle. The inventory processes and supporting technology were slow and cumbersome, ordering, shipping and sales were hit and miss affairs and the information she needed to manage her marketing programs effectively just wasn’t available when she needed it in the form she wanted.

The Marketing VP approached the VP Distribution. He had similar concerns about the operations of the widely dispersed retail outlets. Together they started to chart out an approach that would improve overall performance. Their first priority was to address store inventory. They needed to know what was available at any given moment in terms of age, cost and quantity. They figured if they could get a handle on that information and the processes to keep it evergreen, they could achieve bottom line improvements of $4 million annually between their two organizations, from increased sales and greater store productivity.

The Goal

The Marketing and Distribution VP’s, the co-sponsors, approached the CEO and other senior managers with their plan. Because the VP Distribution had been involved in a very nasty and failed inventory project with another organization and knew the potential risks and pitfalls first hand, he wanted to keep the scope laser focused. The two VP’s pitched their project with a target cost of $6 million and a duration of 24 months with a store by store phase-in to manage risks and hone their rollout process to a razor’s edge. They didn’t know if that was enough money to deliver the solution they were looking for but the dollar target would be essential if they were going to deliver on their plan. The project was approved and funding was allocated as proposed.

The Project

The first thing the two VP’s did on receiving management committee approval was to bring the VP Warehousing into the fold. He had been somewhat supportive in the presentation but had raised a number of issues and concerns. They recognized that the warehouse operations would be a key interface to the proposed store inventory system and they needed him involved if they were going to be successful.

Their next step was to enlist the help of the CIO. They would need technology to support their store inventory and interface to the other in place systems and the CIO’s involvement throughout the technology selection, implementation and operation effort was essential. Also, with the CIO’s assistance, they selected a contract project manager to lead the effort. He had considerable experience with point of sale, warehousing and inventory operations and systems, great references and a solid track record of success.

The project manager proceeded to pull together a comprehensive “request for proposal” (RFP) process and identified eight possible vendors for consideration. Further discussion and review with the four VP’s cut the candidates to five but the VP Distribution proposed one additional vendor be considered as well. The RFP’s went out, submissions were received from five of the six candidates, the proposals were assessed and two vendors were short-listed for the quote process. All of this happened with five weeks of the project manager’s arrival.

The PM had developed the “request for quotation” (RFQ) process while waiting for the RFP submissions and had the blessing of the four VP’s so, as soon as the decision on the short-listed vendors was reached, the vendors were notified and the RFQ was issued. The PM also convinced the four VP’s to expand their evaluation team to include the following members:

Three or four region directors and/or store managers to represent all those in similar roles across the country and to dialogue with store staff
Product managers within the Marketing VP’s group who were responsible for running product specific promotions and sales
The system support manager who would be responsible for maintaining and enhancing any new software and services
The computer operations manager who would be responsible for ensuring the performance and stability of the technology infrastructure and managing the relationship with the selected vendor.

While the short-listed vendors were completing their responses to the RFQ, the VP’s of Marketing and Distribution and the CIO proceeded to engage their managers, reviewing the project goals and objectives and ensuring each understood the critical nature of their ongoing involvement. By the time the completed RFQ’s were received, the PM had a solid, informed review team in place. The vendor review was conducted in two half day workshops plus a half day wrap-up and decision-making session. At the end of the exercise, another five weeks had elapsed but a vendor had been selected and the decision was unanimous.

The winning vendor forecast their costs for software, services and project management support for the defined scope at slightly less than $3 million. The retailer’s internal costs were estimated to be $1.2 million, for a project total well within the $6 million target. Ongoing licensing and support costs were a very manageable $250,000 annually. A senior project manager from the winning vendor was added to the stakeholder team

One of the biggest challenges faced by the PM over the course of the project was keeping the scope constrained to the targeted retail inventory functionality. The winning vendor also had a full suite of software on offer, including components for Client Relationship Management, Vendor Management, Point of Sale, Inventory, Aggregated Inventory, Reporting, Interfacing Components, Web Site Integration, Ecommerce, Employee Management, Accounting and Order Entry. There was considerable pressure from the retail and product managers to expand the scope given the low cost forecast and some of the juicy functionality available. The PM used the MuSCoW approach to keep the stakeholders focused on the task at hand:

M – MUST: Describes a requirement that must be satisfied in the final solution for the solution to be considered a success.
S – SHOULD: Represents a high-priority item that should be included in the solution if it is possible. This is often a critical requirement but one which can be satisfied in other ways if strictly necessary.
C – COULD: Describes a requirement which is considered desirable but not necessary. This will be included if time and resources permit.
W – WOULD: Represents a requirement that stakeholders have agreed will not be implemented in a given release, but may be considered for the future.
The stakeholders agreed on the following Must and Should components to include in the project:
Retail inventory and aggregated inventory to provide the product managers with a local and overall view of stock on hand
Reporting to provide the Marketing and Distribution VP’s and their staff with the timely and comprehensive view of sales activity and inventory across the country.
The Interfaces component was also selected to support automation of the bridges to other critical in-place systems including point of sale, warehousing and the current reporting systems.

The project ramped up, added the necessary internal and vendor staff and proceeded to develop the target solution for initial piloting in one volunteer store.

The Results

The project delivered the first implementation to the selected pilot store 19 weeks after the vendor decision. Training for store staff was conducted in parallel with the technical and systems work so they were ready to go right from the start. A full store inventory was also done and compared to the existing inventory totals. The finding: the existing inventory numbers were so out of whack as to be next to useless. From that point on, a full inventory, performed by a contracted organization, became part of the rollout process.

There were a few glitches in the pilot implementation:

The bridge between the point of sale system and the new inventory component experienced some performance issues that were solved by tuning.
The initial reporting offerings didn’t satisfy the store managers or the product managers and needed some additional work to address the needs. The ad hoc query component, which was initially rated a Would and excluded from the initial release, was added to the scope to provide additional analytical and tracking capability, at an incremental cost of $450,000.
The old manual processes used to ensure synchronization between the sales campaigns, requisitioning, vendor management, warehousing and distribution failed frequently and automating and streamlining work was added to the project scope. The additional cost: $330,000.

The rollout exercise became a cookie cutter operation and store implementations proceeded across the country with military precision. The entire rollout was done in 20 weeks from the successful completion of the first pilot store. Total elapsed time from project inception: 55 weeks. Total cost: slightly less than $5.5 million including the contracted inventory work. Value delivered: an estimated $6.2 million annually.

Of course, the co-sponsors didn’t stop there. They saw immediate opportunities for the client relationship management function and integration with their web site to grow their client base and increase same client sales. While the cross country rollout was in its early stages, the co-sponsors pitched and received management committee approval and additional funding for this additional capability. One of the key arguments they used for proceeding immediately – the team that delivered this highly successful project was already in place and ready to go. It was a clincher!

How These Great Leaders Achieved Success

There were four factors that made this a successful venture:

The Right Decision-Makers
The success of this project was founded on the initial actions of the Marketing VP. She knew she needed help and engaged the VP’s of Distribution as a co-sponsor. That participation in the project helped seal the deal with the CEO and the other executives. They brought in the Warehousing VP and the CIO. They acquired the contract PM recommended by the CIO. They brought in the managers who would ultimately have to make the solution work to assess the short-listed vendors. That positioning and involvement gave the managers the information they needed and generated the commitment required for their subsequent leadership role. Finally, they added a senior manager from the selected vendor. It was a fully formed, committed stakeholder group.
A Skilled Project Manager
The PM was selected based on his domain knowledge and experience, solid references and track record. He knew how to manage scope consistent with the co-sponsors wishes. He knew how to parallel work to reduce schedule impact. He was familiar with RFP/RFQ practices which ensured timely, effective, comprehensive vendor evaluations and an appropriate decision.
Disciplined Scope Control
The fact that the scope of the project started with a very compact focus and stayed largely consistent throughout the project is a testament to the co-sponsors’ initial vision and ongoing discipline. It wasn’t the complete solution but it was enough to deliver the value they had identified. They allowed additions only when the need was apparent to protect their targeted value.
Relentless Focus on Value
You will notice that there was no mention of business cases, budgets or project estimates in this case. Estimates were done by the retailer’s and vendor’s PM’s but only to help guide the work and to ensure delivery within their mandates. What drove the co-sponsors’ pitch? Value! How much can I increase sales? How much can I improve productivity? Reduce costs? When they pitched to the CEO and senior executives, they presented a case based on value. They tempered their case with a limit, the $6 million that would shape and constrain their search for a solution. And it was that limit that turned out to be the significant factor in their vendor selection.

If you find yourself in a similar situation, put these points on your checklist of things to do so you and your stakeholder group mates can be a Great Leaders too. And remember, look at Project Pre-Check’s three building blocks right up front so you don’t overlook a key success factor.

Thanks

Don’t forget to leave your comments below.

From the Sponsor’s Desk – Fifteen Must-Haves for High Performance Teams

Written by Drew Davison on April 10, 2013. Posted in Articles. 6 Comments on From the Sponsor’s Desk – Fifteen Must-Haves for High Performance Teams

FEATURE Apr10th In my last post, we looked 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 engage key stakeholders and manage the project risks and paid the price, in dollars and credibility.

In this post, we’ll look at how one IT organization responded to corporate pressure to deliver more, faster and at less cost by transforming its organization using high performance team principles.

Thanks to reader K.B. for providing the details on this case.

The Situation

In this large financial services company, the beginning of the teamwork initiative was the recognition by the IT organization that demand for its support was growing. Systems and services were on the critical path for almost every business initiative, and the ability to deliver was not improving fast enough to meet the demand.

The CIO had a vision: to transform IT on the model of a professional service firm and thus enhance its contribution to the plans, knowledge and results of the business units served. Her plan included a number of changes to support this vision based on three key principles:

Professional staff would actively manage their own skill and career growth.
Managers would focus on skill development needs and assist the professional staff with their skill and career development.
Work would be handled by teams, which would form and operate on the basis of self-managed team principles.

Information Technology had a reasonably good track record and 600 staff, mostly long-service employees. Most were already involved in teams to deliver computing services or develop application systems, but most of these teams operated in a hierarchical fashion, with team members deferring to managers for direction and decisions. The challenge was to transform the operating style of this organization.

The Goal

The CIO and senior IT managers established a performance improvement target of 30 per cent over 18 months in the twenty teams they designated as priority. Other teams would be supported as the need dictated and the capacity allowed.

The Project

To get the change off to a good start, IT formed a small team, known as the SMT (Self-Managed Team) for lack of a better label. Four of the five team members had from 1 to 23 years of IT experience. The fifth was a former IT staff member working in the Human Resources organization. All worked on the assignment on a part-time basis.

The SMT relied on an external consultant to help understand the issues and opportunities and to give added impetus to the rollout of team principles and practices. The consultant assisted the team with exploratory and planning sessions and two full-day orientation sessions for all IT management and interested business partners.

Two key findings emerged during the orientation and introduction stages:

Most people didn’t really recognize or acknowledge the fundamental differences between the operation of existing teams and the desired operating style of a self-managed team, although participants would nod knowingly if the topic was raised. The ideas behind self-managed teams are not new but they are attractive. Teams and managers were sometimes reluctant to admit that these desirable team attributes were not in place. Consequently, the SMT would hear comments like ‘we’re already self-managed” or “we already do all those things.” Not only did this not foster the desired results, the SMT would have to work very hard to undo these beliefs.
Self-managed teams didn’t just magically emerge out of existing teams because someone said it was a good idea. In fact, because of the perspectives described above, many managers and teams concluded that they didn’t have to change anything. For those who did realize there was a difference, the path to self-management was not clear. With all the other demands on managers and teams, it was easy to put off figuring out how to make it happen.

The SMT addressed these concerns by developing and producing a 30-page booklet presenting the Information Technology version of self-managed teams. The team borrowed ideas from a variety of sources to ensure the material was relevant to IT circumstances and covered the following topics:

what is a self-managed team?
what is a self-managed team . . . not?
why do we need self-managed teams?
requirements for successful self-managed teams
team principles
phases of team development
team boundaries
roles and responsibilities
skills and training
an individual self-check test
where and how to get help

With the booklet in hand, the SMT proceeded to arrange and conduct a two-hour introduction to self-managed teams for all Information Technology and involved business staff. The introduction was based on the booklet (distributed in advance) and structured to provide opportunities for questions and discussion. It was also used to advertise the availability of SMT members to assist with the implementation of self-managed team principles and practices. The sessions were conducted on a team-by-team basis, with the team leader/manager in attendance.

Perhaps the most significant benefit from developing the booklet and conducting the introductory sessions was the understanding and insight the SMT members developed about how to’ make the team concepts work. As a result of the introductory sessions, members of the SMT began to notice an increase in interest and in requests for information and assistance. But the misconceptions didn’t disappear:

“We’re self-managed! We don’t need a manager to tell us what to do!” – a team member

“They’re self-managed! It’s not my job to tell them what to do!” – a team manager

“We say we are self-managed, therefore we are.” – a skeptic

“We’ve always been self-managed.” – an optimist

In addition, while the SMT “thought” things were beginning to happen, they had no measures to establish conclusively how they were doing. It was time to practice what they had been preached to others: clarify the mandate with the stakeholders and establish measures to track performance and progress.

In follow-up meetings with the stakeholders, a number of things were revealed:

The term “high-performance team” was preferred over the term “self-managed team” because it was less open to misinterpretation, provided greater latitude for solutions and placed the emphasis on result rather than method.
The SMT members agreed among themselves to deliver a 30 per cent performance improvement in the targeted teams as well as the ones they chose to assist.

The SMT developed a team assessment tool based on a variety of sources using the percentage change from the first team assessment over the 18 month period as their measurement framework. The team assessment tool addressed team member perceptions on a scale of 1 to 9 on 15 critical success factors for high-performance teams:

Clarity of team mission, vision, goals and priorities
Member and stakeholder acceptance of team mission, vision, goals, priorities
Clarity of specific measures to track performance against goals
Amount of challenge in team’s task
Team’s value to members as a place to acquire new skills
Support for team from sponsors
Skill resources in team (including leadership)
Team’s size
Facilities, technology and support
Team’s reporting relationship with sponsor
Ground rules on team operation, confidentiality, sign-off, etc.
Team roles, boundaries and authority limits
Communication between this and other relevant individuals, groups
Team’s measured performance against established goals
Sponsor satisfaction

The team assessment was completed in a one-hour review with all team members and was facilitated by a member of the SMT. Priorities and action items for the team to address were agreed upon in the review. Subsequent reviews were performed by the team members themselves or with the help of a facilitator.

The Results

The assessments were completed on 25 teams over 18 months, fifteen development teams and ten operational groups. The average result for the initial assessments was 5.2 based on a scale of 1 to 9 where 9 is high performance and 1 indicates a definite need for improvement. Team results ranged from a high of 7.44 to a low of 3.40.

Questions 4 and 5 received the highest initial responses, averaging 7.0 and 7.1, respectively. The lowest responses were reserved for questions 14 and 15, with results of 3.7 and 4.0, respectively.

After eighteen months, assessments revealed an average improvement of slightly over 37 per cent, nicely above the 30 per cent target. Perhaps what was most important was the awareness teams developed when they had been through an assessment two or three times. Team members understood the meaning and significance of the 15 success factors, and team dialogue appeared more open, more honest and more focused on results.

It was also discovered that team performance improvement was seldom linear. Average scores by teams over the eighteen months looked like a chart for the Dow Jones stock index, reaching ever upward and then dropping like a stone in response to some internal or external trauma. Things like the addition or departure of IT or business staff, organization changes that impacted a team’s stakeholders and technology and business process changes accounted for most of the drops. Teams that had internalized the high performance team practices and tools did a much better job of responding to the assessment drop and bringing their scores back up.

It was also discovered that some teams just don’t do very well. Most teams in that category didn’t have the right mix of attitudes and personalities and the collective commitment to learn and grow. Removing problem staff, often initiated by the other team members, and in depth coaching and facilitation usually turned the situation around.

Is the team assessment tool the definitive method for measuring team performance? Absolutely not! The SMT’s ultimate goal was to be able to track the improvements in team performance on the basis of each team’s own measure as expressed in questions 14 and 15. However, even when teams have clear goals and measures, the team assessment tool is a useful catalyst to focus attention on the means of achieving those goals.

Finally, business stakeholders felt IT’s quality, responsiveness and cost-effectiveness had improved noticeably in the twenty-five teams targeted. It was a ringing endorsement for the program.

How a Great Team Achieved Success

The SMT did a number of things right.

They lined up and leveraged the key stakeholders in IT and the business as they went.
They brought in some external expertise right up front to address their own knowledge and skill gaps.
They learned as they progressed and adapted their approaches accordingly.
They built up the organization’s store of best practices around high performance teams, something that was leveraged productively by other departments within the organization that had heard of IT’s success.
They managed to internalize the high performance principles and practices, even with part time commitment. They walked the talk.
They used Project Pre-check’s three building blocks to perfection – engaged stakeholders, a defined process and a best practice based decision framework.

What did they learn from this adventure?

Active and sustained sponsorship is essential. Without the vision and commitment of the CIO and visible support of IT and business management throughout the organization, momentum and interest would have dissipated quickly.
Establish goals and measures up front. This is good advice for any team and absolutely essential for a team charged with implementing self-managed principles and practices.
Communicate! Communicate! Communicate! Celebrate victories. Acknowledge mistakes. Share learnings. Stay on the front page.

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

Don’t forget to leave your comments below.

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

Written by Drew Davison on March 27, 2013. Posted in Articles. 8 Comments on From the Sponsor’s Desk – Tackle Your Project’s Highest Risks First

Davison FeatureArticle March27 In 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.

Don’t forget to leave your comments below.

From the Sponsor’s Desk – Using Coercion for Program Success

Written by Drew Davison on February 27, 2013. Posted in Articles. 7 Comments on From the Sponsor’s Desk – Using Coercion for Program Success

In my last post, we looked at how a director’s refusal to engage the project sponsor on a multi-million dollar reorganization resulted in project failure and his own loss of position. We also looked at the actions project managers can take to identify and engage the right stakeholders in the right roles to improve the performance of their projects.

In this post, we’ll look 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!

Thanks to reader B.F. for contributing the details on this case.

The Situation

This global financial services organization identified a new product opportunity that would generate substantial new revenues and provide a significant competitive advantage over competing firms in all its markets. However, because the product could be duplicated by its competitors once they recognized the opportunity, there was considerable pressure to deliver quickly and quietly.

The Goal

The organization proceeded to launch a program to deliver the new product to all its global markets. The target budget for the total effort was $10 million and three years for full operation. The first implementation of the multi-phased effort was forecast at $7 million with a delivery target of 30 months.

The Project

The program was a top corporate priority and was recognized as such throughout the company. Because of its global impact, funding was provided by each operating unit in accordance with anticipated revenue generation. North America was expected to be the biggest beneficiary and so was the largest contributor, followed by the UK, Europe, Asia, South America and Australia/New Zealand.

The CEO of the North American unit was designated as sponsor and the South American organization was targeted as the first market to receive the new product. A contract program director was selected, reporting to the North American CIO. His team was based in New York and was accountable for planning and guiding business process design, software development and testing using a purchased application and significant vendor resources, acquisition and installation of new technology and the implementation of the whole package, adapted to meet the unique needs of each market.

The program director managed 20 different teams around the world with over 120 direct participants and many more staff involved behind the scenes. He attempted to schedule regular meetings with the sponsor, the North American CEO, to ensure his thoughts and expectations were understood and satisfied but he was rebuffed. The program director was told that the CEO would only be involved on an exception basis. He was to report through the North American CIO and ensure that the fourteen other unit executives around the globe were kept informed.

The program director was a seasoned manager with lots of relevant experiences and insights. He knew the sponsorship arrangement was a significant risk. He also saw the global nature of the effort as major risk. So he implemented the following practices to counter these risks:

He established a sizeable travel budget to cover frequent visits by him and key team members to each affected business unit and for the key business unit staff to visit the facilities in New York. He hoped that the face time with the team members and key stakeholders would facilitate communication, accelerate decision making and ensure the needs of each region were well understood and reflected in the final product.
He built his plans iteratively, putting a high level framework in place that focused on milestones, letting each region build the details within the overall framework and dealing with each unit as issues and conflicts arose. Think globally, act locally.
Once the plans were finalized, he adopted a mantra of “no slippage”, recognizing that failure of any one element to deliver on plan and budget would have massive ripple effects across the entire program. He repeated this message with all teams, with all stakeholders, in all offsite meetings, in all program meetings.
He established weekly conference calls to review the progress of each of the 20 teams against plan. Attendance was mandatory but teams could drop off after their report was presented and vetted.
Finally, the program director used coercion in place of an engaged sponsor. The program was seen as a career opportunity by a number of local VP’s and directors. They attempted to make their marks by challenging decisions, by criticizing program direction and progress and demanding additional capability. However, the program director felt he had enough senior management representation and backing around the world to ensure the project was addressing enterprise needs. So when he was challenged by a rogue director, he stressed that the sponsor was fully on side with the direction and progress and used the threat of the sponsor’s wrath and potential reprisal to thwart the attack. Fortunately, no one had the courage to push their points further. Coercion was a most effective .strategy!

The Results

The program was delivered on time with a 20% budget overrun, which was due largely to incremental support for localization needs. The first implementation in the South American market disclosed a number of product design, process and software issues which were quickly remedied. The phase-in strategy helped subsequent releases to proceed flawlessly.

All those involved in and affected by the program where unanimously enthusiastic. Ironically, the uninterested and uninvolved sponsor received, and accepted, accolades for his “insightful vision and superb leadership”. Remember my first post at Project Times in May, 2010? A Great Project Manager – the Sponsor’s Best Friend! How true.

How a Great Program Manager Helped

We know that the ability of programs and projects to deliver the expected functionality with appropriate levels of quality, on budget and on schedule and achieve the anticipated benefits declines as the size of the initiatives increase.

In this case the program director did a number of things right to address the size and virtual team challenges and achieve a successful result:

He focused in on the key stakeholders and their roles shortly after getting the job. That helped him understand the dynamics of the program and the personalities of the players.
He identified the key risks and developed mitigation plans to circumvent the challenges.
For the absentee sponsor risk, he built a coalition of support among the other stakeholders and actively managed those relationships and that support throughout the project.
He also used coercion and the threat of sponsor displeasure to ward off wayward executives.
For the risk posed by the involvement of 20 teams around the globe and including technology and software vendors, he traveled, his team traveled, the business leaders traveled, all to facilitate face to face dialogue. That helped build understanding, collegiality and a shared understanding and commitment to the goals to be realized and the solution that would deliver to each unit’s unique needs.
His approach to building and managing the program plan was a masterpiece of conceptualization and salesmanship. He got the teams to buy into the overall approach and milestone plan by fully engaging them in its development. Once committed, the teams built their detail plans in support of the master plan.
His tracking and control approach of mandatory weekly conference calls and the “no slippage” mandate helped reinforce the collaborate culture that was nurtured by the frequent face-to-face engagement. It placed accountability to deliver to plan firmly on each team, helped raise cross team issues yet put resolution at the local level.

What else could the project director have done to improve the result? One of the building blocks in Project Pre-Check is the Decision Framework, a model with 125 best practice based decision areas that enables early discovery of program scope and impact. It facilitates stakeholder deliberations about the breadth and depth of the planned change leading to full agreement on project and program content, direction and conduct. Use of a Decision Framework may have helped identify those localization needs and address some of the product design, process and software issues earlier in the program’s life cycle, leading to improved quality, faster delivery and lower costs. He promises to use it on his next project.

The program director admitted that he was exhausted at the end of the three year project, largely from the amount of travel required. He took a well-deserved sabbatical after the program was wrapped up, financed by the air miles he accumulated during the project. A well deserved reward.

Don’t forget to leave your comments below.