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 – Focus on Value, Not Budget

davison FeatureArticle May22In 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:

  1. 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.

  2. 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.

  3. 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.

  4. 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. 

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.


Don’t forget to leave your comments below.

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

FEATURE Apr10thIn 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 in­itiative was the recognition by the IT organization that de­mand for its support was growing. Systems and services were on the critical path for al­most 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 de­velopment needs and assist the pro­fessional 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 reason­ably 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 man­agers for direction and decisions. The challenge was to transform the oper­ating style of this organization.

The Goal

The CIO and senior IT managers established a performance improve­ment 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 for­mer 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 con­sultant to help understand the issues and opportuni­ties 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 inter­ested business partners.

Two key findings emerged during the orientation and introduction stages:

  • Most people didn’t really recognize or acknowledge the fundamental dif­ferences between the operation of existing teams and the desired oper­ating style of a self-managed team, although participants would nod knowingly if the topic was raised. The ideas be­hind self-managed teams are not new but they are attractive. Teams and managers were sometimes reluctant to admit that these desirable team at­tributes were not in place. Conse­quently, 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 re­sults, the SMT would have to work very hard to undo these beliefs.
  • Self-managed teams didn’t just magi­cally 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 differ­ence, the path to self-management was not clear. With all the other de­mands on managers and teams, it was easy to put off figuring out how to make it happen.

The SMT addressed these concerns by de­veloping 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 cov­ered 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-man­aged 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 opportuni­ties 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 con­ducting 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 ses­sions, members of the SMT began to notice an increase in interest and in re­quests 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 es­tablish 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:

  1. Clarity of team mission, vision, goals and priorities
  2. Member and stakeholder acceptance of team mission, vision, goals, priorities
  3. Clarity of specific measures to track performance against goals
  4. Amount of challenge in team’s task
  5. Team’s value to members as a place to acquire new skills
  6. Support for team from sponsors
  7. Skill resources in team (including leadership)
  8. Team’s size
  9. Facilities, technology and support
  10. Team’s reporting relationship with sponsor
  11. Ground rules on team operation, confidentiality, sign-off, etc.
  12. Team roles, boundaries and auth­ority limits
  13. Communication between this and other relevant individuals, groups
  14. Team’s measured performance against established goals
  15. Sponsor satisfaction

The team assessment was completed in a one-hour review with all team mem­bers 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 them­selves 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 re­sult 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, assess­ments revealed an average im­provement 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 under­stood the meaning and significance of the 15 success factors, and team dia­logue 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 de­finitive method for measuring team per­formance? Absolutely not! The SMT’s ultimate goal was to be able to track the im­provements in team performance on the basis of each team’s own measure as ex­pressed 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 ad­venture?

  • 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, mo­mentum and interest would have dis­sipated quickly.
  • Establish goals and measures up front. This is good advice for any team and absolutely essential for a team charged with implementing self-man­aged principles and practices.
  • Communicate! Communicate! Com­municate! Celebrate victories. Ack­nowledge 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.

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 – Tackle Your Project’s Highest Risks First

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.

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.

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 too can be a Great Program 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.

From the Sponsors Desk – For Best Results Use Your Sponsor Wisely

In my last post, we looked at Project Interlopers – project players who are often contributors to project difficulties and project management migraines – and how they can negatively influence project outcomes. We also looked at steps you can take to counter their negative impact and improve the performance of your own projects.

In this post, we’ll look at how a director’s refusal to engage the project sponsor on a multi-million dollar reorganization effort resulted in project failure and his own loss of position.

Thanks to reader G.M. for contributing the details on this project.

The Situation

This public sector organization had a multi-year plan to improve the responsiveness and cost-effectiveness of its IT organizations to deliver $100 million in annual savings. Part of that plan was the consolidation of four local service desks into one virtual service organization.

The Goal

  • Reduced cost of Service Desk and associated services
  • Provide a consistent level of customer service for service desk and associated services
  • Provide a single point of contact for technology users to report incidents and make service requests
  • Provide a single organization responsible for providing standard services to the organization’s technology users.

The Project

The project was launched to great fanfare, with an announcement from the CIO outlining the goals and addressing plans to close the local service desks and consolidate the functions and staff in a remote, virtual site, accessible by phone, email and web services.

A new director was appointed by the VP Technology Services to form and operate the new organization, transfer staff from the local centers, acquire additional staff as needed and put the services and technology in place. The new director proceeded to hire a project manager to guide the process design and implementation and manage the technology initiatives necessary to support the new service desk operations.

The new director found that very few of the existing service desk staff were willing to transfer from their existing communities to the city where the new organization was based. That meant that the hiring and training challenges were significantly greater than originally anticipated. In addition, the new director faced considerable resistance from the architecture and IT operations organizations over the technology that he wanted to use to support many of the service desk functions. The estimated project and operating costs ballooned and the target dates slipped and slipped again.

The director and his PM tried to phase in the new service one local service desk at a time. However because of the cost and schedule slippage, the local service desk managers were reluctant to release their staff and the technology users continued to make use of their local service desks, leaving the new consolidated unit with significant excess capacity.

The Results 

The new service desk director continued to build his organization but much of the technology supporting its operation was legacy offerings from the local service desks. Because of this, the service experience was not a terribly pleasant one for technology user. They continued to frequent their local help desks for assistance where they knew the staff on a first name basis, could drop in unannounced with their questions and problems and receive the same personalized, friendly service they had become accustomed to over the years.

The new director had no authority over the local service desk managers (they reported to a peer director) so he couldn’t unilaterally close them down and the director who oversaw the local help desks was in no hurry to close them down because of the negative feedback he was receiving from technology users about the service of the new organization. It was a costly mess.

With a growing number of complaints from technology users and an increasing number of questions from the executive ranks, the CIO was forced to pull the plug on the new consolidated service desk. The director and PM were reassigned. The staff were either reassigned or let go. The price paid: $3 million in operating costs and $1.5 million in project costs. The cost of the reputations sullied: priceless!

How a Great Project Manager Would Have Helped

Sometimes on projects, perception is not reality. The new consolidated service desk director thought he was the sponsor of the initiative he was heading. The project documents actually stated that. When asked how often he interacted with his VP, he replied “only when I need his signature”. In reality, the director was a target, a manager of an organization that is affected by a change much larger than his span of influence. The real sponsor should have been the VP Technology Services, who had authority over both the local help desks and the new organization. He was also on a peer level with the heads of the architecture group and IT Operations, the two organizations that were resisting the new technology that was essential for a superior user experience.

So, what could the project manager have done to remedy the situation? Here are a few questions he could have posed to get the discussion about stakeholder roles and responsibilities underway and hopefully change the game:

  • What organizations need to be involved and change the way they operate for the project to be successful?
  • Which managers have the authority to allocate time, costs, resources and establish priorities in those organizations?
  • What explicit role will each of those managers play on the project – sponsor, change agent, target or champion?

In my Project Pre-Check practice, a stakeholder is a decision maker who:

• Directs an organization that initiates, is affected by or is charged with managing all or part of a change,
• Has the authority and responsibility to set direction, establish priorities, make decisions, commit money and resources and
• Is accountable for delivering the planned benefits on budget and on plan.

Stakeholder involvement and commitment is one of the most important ingredients for successful business and technology change. Let’s look at what probably would have happened if the right decision makers were involved in the appropriate roles:

  • We would have had the following players sitting around the stakeholder table:
    • The sponsor – VP Technology Services
    • Targets – the new director of the consolidated service organization, the four managers of the local help desks, the heads of the architecture group and IT operations (because of the impact of the new technologies) and someone representing the interests of the technology users (because of the changes in the service desk location, processes and technologies)
    • Change Agent – the project manager, who would take his primary marching orders from the sponsor as well as addressing the needs of the targets.
  • Those stakeholders would have been committed and engaged from project inception through completion.
  • The issue of relocating staff would have been addressed and perhaps the location of the new consolidated center would have been changed to facilitate staff moves.
  • The technology choices would have been addressed with the buy-in of all stakeholders, including those representing the interests of the technology users.
  • The phased close out of the local centers would have been managed in concert with the phase in of the new service desk.
  • The technology users would have been much more amenable to the new service, processes and technologies because of their upfront engagement and ongoing involvement in the decisions affecting their world.
  • The incremental operating costs would have been eliminated or minimized.
  • The reputations of the CIO, Director and project manager would have been preserved and probably enhanced.

I know this analysis is hypothetical. However, without the right players in place and the right guiding coalition going forward, the project was essentially doomed from the start.

The stakeholder group is a most powerful force for enlightened project guidance and an essential resource for project managers. But it needs to be nurtured and cultivated from project launch. That’s why it’s central to Project Pre-Check’s model, processes and Decision Framework. It is a great place to start your project and supplies a terrific framework for building an effective guiding coalition that will be there when conflicts and crises arise.

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 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.