From the Sponsor’s Desk – The Calm before the Storm, Project Style

Most projects start out blissfully don’t they? They have their sponsors, their charters, their teams. The scope looks reasonable.

The plan looks doable. The budget appears manageable. The sponsors seem committed and energized. The team has the right number and mix of skills. I like to call this initial period the calm before the storm, project style.

In this case, we’ll follow the journey a systems integrator took from the beginning of a fourteen-month project, through an initial six week honeymoon period, into a painful realization that all was not well and enduring a series of traumatic battles. We’ll also learn what it took to turn the situation around and deliver a successful outcome for all involved.

Thanks to John Cognata for the details on this case.

The Situation

John Cognata is responsible for business development at SOFTEL Communications, a system integrator with expertise in voice recognition, voice biometric and VoIP enabled contact center services, unified communications and mobility applications and technologies.

John was approached by a large telecom company to deliver a key component of a solution the telecom company was proposing to one of its clients. The telecom company had developed the specifications for the component and reviewed them with John and his team at Softel.

Based on that review, the Softel staff developed a plan with an estimate and presented it to the telecom company. The plan was accepted and Softel was awarded the contract.

The Goal

To deliver the component according to the specifications provided by the telecom company within the plan and estimate provided by Softel. The project was to be completed within fourteen months on a fixed price contract.

The Project

Softel assembled a team to take on the project. It included fourteen people, with a project manager, software development staff and telecom engineers. The team got right to work, using the specs developed by the telecom company to build the new component. Progress was excellent, for about six weeks. And then the change orders started coming.

The management structure for the overall project included a steering committee that met bi-weekly. That committee included representatives from the telecom company, their client andSoftel. But the Softel representatives were not being notified of the meetings and so were not in attendance. Further, the change orders that were being approved at the steering committee were not being reviewed with Softel beforehand.

Of course, Softel treated the change orders as add-ons to the original specs, above and beyond the fixed price contract. The client argued that the changes were actually corrections to the original specs and would not cover any extra costs. The client also had a very talented project manager who was skilled at working the telecom company against Softel.

Matters were further complicated by the relationships between the three parties. Softel was the telecom company’s supplier. They had no formal working relationships or communication channels with the telecom company’s client. All communication between the client and Softel had to go through the telecom company. To make things worse, the director at the telecom company who was responsible for the engagement was a “take no prisoners” manager. He was belligerent, bellicose and a bully. Disputes over the disposition of change orders turned into one way shouting matches with Softel staff on the receiving end.

In addition to the escalating change orders and the relationship and communication challenges, Softel discovered that the telecom company’s component design included adding additional features to a switch from a hardware vendor that were not standard practice. That hardware vendor was not actively engaged in the project, other than as a hardware supplier.

As the change orders mounted, conflict escalated and progress stumbled. While John was not actively involved in the project, he could see the impact the struggles were having on the Softel team. They were also threatening the targeted profit margins for Softel. John knew that the status quo was not a viable option for any of the parties. So he started a dialogue, initially with the telecom company’s director. John was yelled at, threatened, harangued and dismissed on more than one occasion. But he persisted, always focusing on the need for a successful outcome and the good names of the involved parties. Eventually, he wore the director down and the director agreed to a meeting with the client’s change sponsor and project manager. Tellingly, the sponsor and PM were also becoming increasingly dissatisfied with the course of the project. The request for the meeting was quickly accepted.

John’s approach in these engagements was always to address the WIIFM (What’s In It For Me) perspectives of the parties involved. That got the players talking openly about their frustrations and the remedies they thought would provide solutions. Common proposals were quickly adopted. Opposing positions were broken down further to find elements of common ground. Eventually, a consensus was achieved on the way forward. It involved:

• Bringing in the hardware vendor as an active member of the team to provide advice on the most effective ways to leverage their technologies.
• Restructuring the steering committee to include representatives from all four parties, meeting weekly until the project was back on track and requiring unanimous decisions on all change matters.
• Reviewing all change requests with the respective teams before submitting the recommendations to the steering committee for approval.
• Reviewing the change orders to date and resetting the contract and baseline to reflect included specs and incremental work.
• Revising the plan to include a limited pilot and three releases instead of the one “big bang” implementation. That would provide shorter term goals to focus inter-company collaboration and create opportunities for quick wins and to manage risks.
• Communicating the changes and ongoing progress with all team members and the client’s affected operating staff.

And so, the work progressed with a renewed sense of optimism and cooperation.

The Results

The initial pilot was implemented with some initial hiccups quickly addressed. The learnings were incorporated into the three subsequent releases. Those releases went off without a hitch but extended the project out to sixteen months. Regardless, all parties were supremely pleased with the results. Softel also met its profit targets and now has three new referenceable accounts.

How a Great Leader Succeeded

John and his team at Softel have some bruises to show for the experience. But, they also learned some valuable and sustainable lessons:

1. Stakeholder Engagement – Ensure that every party whose involvement is essential for a project’s success is actively engaged by focusing on WIIFM. This project wasn’t about implementing a proven turnkey solution. It was focused on creating and delivering a custom crafted creation for the client. It required hundreds if not thousands of decisions along the way. Every party needed to be involved in that decision-making process.
2. Governance Structure – Make sure that the governance structure and processes reflect the stakeholder population. Whatever you call it – steering committee, guiding coalition, oversight body – its makeup and operating practices need to be embraced by and executed consistently by its members.
3. Incremental Delivery – Having one big implementation after fourteen months of effort is a risky, tedious exercise. There’s less opportunity to learn and adapt. There’s less opportunity to deliver value incrementally, to innovate, to celebrate successes, to recognize contributions. Make sure your project delivers something of value every six months or less.
4. Realistic and relevant project baseline – Having a realistic and accepted project baseline is vital for effective project guidance and decision-making. As those disputed change orders and design issues escalated without resolution, the usefulness of the original baseline diminished and the ability of the players to managed time, cost and functionality dissipated proportionately. That baseline must be established and maintained throughout the course of the project.
5. Standard Practices – Every project will have to deal with issues, changes, assumptions, risks and communication needs. Leveraging industry standards and ensuring all parties understand and agree on the practices, adapting as necessary, will go a long way towards ensuring effective and efficient project conduct. In this case, having a change control practice that excluded the developer from the decision-making process, no apparent issue management method and flawed communications was a recipe for disaster.
6. Communication that binds – Communication practices that engage, inform and facilitate collaboration and consensus among all parties are a project management key success factor. In this instance, there was no vehicle initially for Softel to communication with the client, and vice versa. The hardware vendor wasn’t involved at all other than to provide the hardware. The communication structures put in place to correct those initial deficiencies were a big contributor to the project’s ultimate achievements.

John’s redirection of the project to a successful outcome was rooted in his initial and ultimately successful efforts to engage all the key players. No doubt those initial encounters with the telecom company’s director were painful. But his perseverance paid off handsomely for all involved.

So, be a Great Leader. Put these points on your checklist of things to consider so you too can be a Great Leader. Also remember, use Project Pre-Check’s three building blocks covering the key stakeholder group, the decision management process and Decision Framework best practices right up front so you don’t overlook these key success factors.

Finally, thanks to everyone who has willingly shared their experiences for presentation in this blog. Everyone benefits. First time contributors get a copy of one of my books. Readers get insights they can apply to their own unique circumstances. So, if you have a project experience, good, bad and everything in between, send me the details and we’ll chat. I’ll write it up and, when you’re happy with the results, Project Times will post it so others can learn from your insights. Thanks