From the Sponsor’s Desk – Six Strategies to Manage Project Chaos

“Our real discoveries come from chaos, from going to the place that looks wrong and stupid and foolish.”
― Chuck Palahniuk, Author

I’m sure we’ve all been racked by project chaos at one time or another – too many conflicting priorities, lack of clarity, directional changes, unanticipated influences, not enough resources or not enough of the right skills, technology troubles… And then there’s the old squeeze play, an immoveable target date and lots of unanticipated and mostly uncontrollable delays.

But sometimes, out of chaos comes clarity – new awareness, new insights, new skills, new confidence, great new relationships, and the realization that, in spite of how dark the situation looks, there are almost always paths to success. That’s where the six strategies to manage project chaos come in.

In this story, we’ll hear about the actions taken by an individual, his team and his organization to extricate his project from certain doom. We’ll see how those actions turned a potentially disastrous outcome for his company and its client into a successful achievement. And we’ll discover the new capabilities and realizations the experience delivered for the individual and the organization.

Thanks to Ian MacGillivary for the details on this story.

The Situation

This small North American technology services company provided custom software development and infrastructure deployment services to a variety of clients. A niche service was the development and installation of kiosks with custom software for trade shows and sales demonstrations.

The company was approached by a major telecommunications vendor to develop and deliver a smart phone application in support of a new service they were launching in four months time. The demo app was to be installed on 4,500 phones and 500 Android and Windows tablets each.

Ian MacGillivary was the Infrastructure Deployment Specialist. When the request was received from the telecommunications company, Ian was asked to provide a plan and estimate for the rollout work. This project was on a much larger scale than their usual contracts but, using his experience on similar but much smaller projects, he figured 15 minutes per device would do the job. He developed the estimate and plan and passed the information back to the Vice President responsible for their bid.

They were awarded the contract!

The Goal

To develop and install the custom demonstration software on the smartphones and tablets and ship them to 2000 target sites by the target date four months hence within the parameters of the fixed price contract.

The Project

Ian had recognized that his firm did not have the staff nor the facilities to handle the volume of smartphones and tablets the customer required. He had recommended contracting with another firm with those capabilities. He interviewed three firms who had the experience to provide the services they sought but their estimates for the effort required varied widely and differed substantially from his own. He passed on his recommendations and waited for a decision.

Concurrently, the signing of the contract with the client was delayed. That meant that the development of the software, the shipment of smartphones and tablets from the client and the delivery of the location addresses and specific guidance on smartphone and tablet disbursements were also delayed. But the target date stayed the same. What started out as a four month duration project was being compressed daily.

Ian went back to the drawing board and redrafted his plan from the target date back. The reworked plan provided ten weeks to get the job done versus the original sixteen weeks. When the contract was finally signed, there were just seven weeks left to the target date. The plan was reworked again, this time with even more activity overlap and compressed time frames.

A vendor was selected to manage the build process, one that Ian had not interviewed. As he brought them up to speed on the project and started to assign work, they stumbled. Ian stated “They assumed it would be a simple install the device, put it in box job. We sent them the initial installation steps, and the initial configuration, and we could cut the tension with a knife.” It became apparent that they weren’t up for the job.

Another vendor, one of the ones that had been interviewed and the most expensive, agreed to take on the job. They were accomplished at large scale rollouts. They immediately pointed out gaps in the plan:

• Security: 5000 or so devices have a book value in the millions of dollars. That required security guards, cameras, a metal detector.
• Space: How much space does 5000 devices take up? Where are they going to be stored? How are they going to be moved? With the numbers involved, a loading dock was essential for shipments in and out.
• Packaging: were the devices going to be packaged individually or by destination?
• Shipping supplies: How many shipments? How many boxes and plastic envelopes? How many mailing labels?
• Desk space: how many people configuring and packing devices?
• Process control: How do you plan on ordering the work, on tracking the work?

As the challenges mounted, the client added another wrinkle: they wanted to track usage of the devices by location. That meant an analytics function was required and each individual device needed to be assigned to and tracked by location. Another surprise: the plans assumed the Windows tablets would be Android tablet sized.

When the very large boxes arrived, it was discovered they were all-in-one Windows PC’s with 18” screens. The plans and procedures were reworked again.

And the work continued.

The Results

In the end, the smartphones and tablets equipped with the demonstration and tracking software were received by all target sites prior to the planned launch date. Only one problem was reported – a device went to the wrong location. The location had been closed prior to the project but the destination list had not been updated by the client.

Unfortunately, the profit targets for the project were not achieved because of the switch in vendors, the compressed time frame and the added costs involved. But, the company did have a satisfied client and a boatload of lessons learned.

What a Great Team Learned

Think about it! A project involving the custom configuration, packaging and delivery of thousands of devices across the country, originally planned for 16 weeks and ending up with less than half of that, and still successfully delivered! Ian looks back on the following lessons learned:

1. The Human Factor – As Ian stated, “At the end of the day, everyone pulled together. Directors were at Kinkos getting papers printed at 3:00 am, developers were running our staging floor and Vice Presidents were bringing coffee. Everyone, when the chips were down, did everything needed. To me, that was the only way we could have survived and executed the project successfully. Everyone wanted things to succeed and for us to do well. The buy in of the organization, and of the people in the organization was, in the end, the key factor”.
2. Getting the scope right – Locking down the scope is essential, especially in fixed price contracts. More time up front with people who had the experience would have helped immeasurably. According to Ian, “one big problem with the project was we under-scoped the logistical arrangements. I still have my original plan, and even that was scarily under scoped. Even the project team was under-scoped. A lot of people had too much span and not enough depth. We always had to go back and add in more space, more people, more, more, more”. At the end of the project, the Vice President stated “next time we decide to be ambitious or try something new, we do it as time and materials”.
3. It’s the little things – The little things are what cause projects to go off the rails. It is the classic “for want of a nail”. According to Ian “Not understanding one word in a statement of work caused hundreds of hours of heartache, misery, and nearly caused us to miss the deadline. Not communicating about the requirements for networking, cost tens of thousands of dollars in direct cost, and lost productivity. Not looking at box size caused a massive overrun in costs. Fortunately the client was willing to swallow that. Not adding in a QA / Documentation person caused things to be left until the last minute. All of that was overcome, yet if we had taken more time, more attention, and focused on the little things, we would have avoided it all.”
4. Early decision making – Decisions made earlier cause less issues with the project than decisions that are put off until later. As Ian stated, “We always had the problem of not making decisions quickly enough early on. We never were able to get ahead of the 8 ball. Things cost more in a rush. By the end of it, we would have paid double if we had to. Decisions often times became bogged down in the mud. This cost us time.”
5. If it’s a priority, treat it that way – Unfortunately, the practice at the company was to assign staff to multiple projects based on availability to maximize productivity and minimize bench time. As demand escalates, the work load on individuals also increases. Ian and a number of staff involved in the project put in 100 hour weeks. Tired people make mistakes. Fatigue costs productivity.
6. The importance of simulation, gaming and tabletop exercises – Gaming out scenarios, simulating, having the project team run and talk out tasks on a tabletop would have allowed for better optimization when executing the project. According to Ian, “On the project, we simulated a lot of things. However, they always were limited. We weren’t able to look at the whole install procedure until late in the project. We never stopped to play things out. We were forced to do things haphazardly or in small chunks to react to problems. If we all had sat in a room and ran a table-top exercise of how this would work from start to finish, everything from box opening, to shipping, we would have been able to find our holes and our weaknesses and actually have a realistic understanding of what was required. One of the big things was that there was never an entire team simulation, from start to finish.” As Ian explained “I wanted my 78 year old aunt to be able to read the process and be able to execute.”

These six lessons learned helped Ian and his organization survive a very challenging situation. Hopefully they will also inform their actions going forward, serving as proven strategies for managing project chaos.

So, be a Great Leader. Put these points on your checklist of things to consider so you too can conquer, or preferably avoid project chaos. Also remember, use Project Pre-Check’s three building blocks covering the key stakeholder group (including the key stakeholder roles), 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