From the Sponsor’s Desk – The Champion’s Dilemma

In my last post, we reviewed an executive’s response to his company’s revenue declines brought about by the financial meltdown in 2008 and the creative steps he took to deliver rapid responses to his company’s challenges.

In this post, we’ll look at the challenges experienced by a project manager who saw an opportunity to improve the organization’s performance and took it without official support. He launched a project to reduce the costs and time required to test the functionality for the consumer electronics device he and his team were supporting. It was a learning experience.

Thanks to T.R. for the details on comments on the case.

The Situation

This consumer electronics company offers hundreds of devices to consumers around the world, from bread machines to TV’s, DVD’s to power toothbrushes. Most of those devices include a variety of functions and customization options and a user interface that allows consumers to access the device functionality. Where language is a component of the interface, the company provides support for the languages in use in the markets in which the devices are sold. When a device is changed, to introduce new functionality or better performance, or to gain cost efficiencies, the core functionality and interface are invariably affected. New versions are developed and tested for each supported language, a costly and lengthy process. 

In the release in question, the project manager guided a feature team of twenty engineers who developed and adapted the functionality of the various components and interfaces on the device. That included a small team catering to component and integration testing. Another team looked after the final testing of all the devices in the product family. 

The project manager for the feature team saw an opportunity to improve testing effectiveness and turnaround time that would reduce the time and cost of getting device changes to market. Quality, cost and time to market were critical to the product’s success. The existing practices, mostly manual and very labour intensive, took almost three person years of effort for each change cycle and almost a year elapsed time to cover the languages supported by the device. 

The PM tried to interest his manager in the venture by pointing out that the six related devices in the product family all had to go through the same testing trauma. That amounted to almost 18 person years of effort for every product release. He also suggested moving to a more agile approach to improve responsiveness in place of the waterfall style practices then being used. His manager could have increased the priority and provided the necessary funding but he couldn’t be sold on the idea. The status quo ruled! 

Unfortunately, without an official sanction and the resourcing and funding to go along with it, the PM couldn’t consider available quality planning, testing and management tools on the market. Nonetheless, determined to make a difference and with the support of his team, he assigned two of his staff to try and automate some of the testing practices. Any progress they made would depend solely on the initiative, spare time and enthusiasm of the engineers on his team. 

The Goal

The project team’s goal was to reduce the effort and time required to test the device in all supported languages and produce a better quality product as a result. Because of the unofficial nature of the project, there was no formal budget or delivery target. The PM also hoped to build the skills of the engineers on his team.

The Project

The project manager and his team went to work. The challenge was to compare the expected results for all possible execution paths and all languages to the results actually presented in the component outputs and interfaces. Their first approach was to build a tool that recorded the expected results. Another set of tools captured component outputs and actual interface layouts and text. A third set of tools compared the results and generated reports identifying the differences.

The team implemented and tested their approach on one of the fifteen execution paths. These were crude tools and it took considerable time and effort to get them working to the point where results could be produced. What they discovered on the one path they tested was a worthwhile reduction in the elapsed time needed to complete a testing cycle. Unfortunately, they encountered a number of obstacles along the way, including lack of language knowledge and shifting priorities which meant they weren’t able to complete the work on time. The project was put on hold, the testing was completed the traditional way and the team members were reassigned. 

Nevertheless, the PM with thrilled with what they had been able to achieve on a shoestring budget. He reviewed the results with his manager expecting a positive reaction and, hopefully, sufficient funding and resourcing to complete the job in time for the next product release. Instead, he earned his boss’s wrath. His boss chastised him for wasting scarce resource on an unauthorized venture and setting a bad example for his team members. 

The Results 

It’s clear most of the goals of this undertaking were not achieved. Testing time was not cut. Costs were not reduced. Quality was not improved. In addition, the engineers trying to deliver the improved test practices cut corners. They didn’t start out with an overall architecture or design which resulted in considerable rework and slowed their progress. They didn’t have a risk plan of any kind. They didn’t track issues and changes effectively which impacted the interoperability of the tool sets. They didn’t fully consider their resource needs, human or technical. However, there were some learnings that, hopefully, will yield substantial returns in the years ahead. They included:

• Get your stakeholders engaged and involved up front. That is especially true of the sponsor role, the individual that establishes the priority and provides the funding to see the project through to completion.
• Develop the specific project goals and expectations to encompass the frames of reference for all stakeholders. Engaging the leaders of the other product teams and the test team may have helped articulate a more saleable target and overcome some of the obstacles encountered.
• Determine your project’s impact on and involvement with the external and internal environments and the productive use of proven processes and practices to help manage scope, risk and value. A little collaboration, forethought and discipline about what you’re trying to do, how you’re going to do it, who needs to be involved and what aids are available can make a huge difference in the outcomes.

After the fact, the PM looked at the elements that he considered when launching and shaping his project against the Decision Areas included in the Project Pre-Check Decision Framework. The Decision Framework includes 125 Decision Areas that should be considered on each and every project to understand the depth and breadth of the planned undertaking and to monitor the stakeholders’ expectations and views on each one through project completion. Here’s what he found

• Overall, of the 125 Decision Areas in the framework, his project considered 25, including things like the opportunity, goals, requirements, benefits, locations affected. Decision Areas that weren’t considered including target dates, phasing and staging opportunities (although they did actually phase their development), quality factors, assumptions, risks and sponsorship requirements.
• Of the 125 Decision Areas included in the Framework, he identified 100 as relevant, including the 25 he did consider. That means there were 75 Decision Areas that were not considered but may have been material to his initiative. They undoubtedly would have helped him build a more compelling case, sell the stakeholders on the importance of the undertaking and see it through to completion.

It’s easy to understand why a more holistic approach wasn’t taken. When the priority of your project is uncertain and your level of funding and staffing will vary accordingly, it’s difficult to justify the time and effort to fully explore the undertaking and engage the stakeholders. Conversely, without that investment, the chances of success are substantially reduced. That’s the champion’s dilemma.

How a Great PM Will Approach This Kind of Challenge Next Time

There is no doubt this project was a learning experience for the PM and his team. They saw the low hanging fruit. They just weren’t able to harvest it. The next time this PM is presented with a similar challenge, I expect the approach will be different:

• He will continue to look for opportunities to improve his organization’s effectiveness.
• He will continue to challenge his team to try new things, to build new skills, to prototype and test ideas.
• He will, however, make sure that all the stakeholders are identified, engaged and committed. When the should-be sponsor is reluctant to support an initiative, often the other stakeholders can help build a compelling case and influence the reluctant sponsor-to-be, either directly or indirectly. In other situations they can help go up the organization or around the bottleneck to secure the necessary sponsorship.
• He’ll use the Decision Framework or something similar to ensure that the impact and influence of the project is fully understand and managed on an ongoing basis.
• He’ll also use the Decision Framework to identify and leverage available processes and best practices and to build team skills and improve project performance.

Before you jump in and try and solve a problem or take advantage of an opportunity on your own, identify and engage your stakeholders. If you and your team are the only stakeholders, great. Go for it! But that is seldom the case. It can be a challenge selling your sponsor and targets on the significance of the venture. But that’s what champions do. They garner support, commitment, priority, funding, appropriate timing, rational dependencies and managed risks. Remember, great stakeholders make great projects! 

If you find yourself in a similar situation, put these points on your checklist of things to do so you too can be part of a Great Team. And remember to use Project Pre-Check’s three building blocks right up front so you don’t overlook those 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.