A financial institution project team was working through some organizational changes in the months before a merger. One of the regulatory agencies had recommended the changes. The team had not worked together before and was comprised of representatives from both banks, and a few independent contractors from a leading consulting firm. The team members were working from multiple cities.
The pressure was on to complete the project before the merger took effect and tempers were high. The project team members were starting to point fingers of blame and make excuses. The project manager was spending an eternity on a detailed Gantt chart that would take 50 pages of paper to print.
The problems, in addition to the personality conflicts that had been bubbling for weeks included:
- It was hard to mark items as done because executives at both banks kept changing their minds. No one was really in charge yet.
- New items to be done kept getting added to the Gantt chart. First, people kept uncovering things that had been forgotten. Second, as guiding decisions kept changing, new activities needed to be done.
- Different people on the team had different ideas about the quality of the work that needed delivering. Some were perfectly happy with misspelled words, changing tenses, and missing punctuation, while others wouldn’t even read a draft if there were mistakes.
- Two people on the team had already quit. With the merger details partially announced, people who didn’t want to move and could see the handwriting on the wall, were actively looking for another job – and had no commitment to seeing this project through.
This scenario, or others quite similar to it, unfolds around the world frequently.
So, what are some suggestions for rescuing projects in chaos?
Focus on the people.
Regardless of what project approach, what project software, and what project details you are juggling, it’s the people who will do this project. What is their motivation for working on the project? What are they enjoying and what are they not enjoying? What can you do to keep their motivation up? Understanding why people are actually working on your project may help.
And when you start focusing on people, don’t forget that there are other stakeholders that need to be considered. Knowing people’s hot buttons is important.
Develop a compelling ‘why?’ statement.
This project was recommended by the regulatory agencies and yet there were still problems. In the automation of medical records, which was required by the Federal government, there were big problems too. Working on projects that are mandated by a government body is not necessarily motivational. Why are you doing the project? How can you turn that ‘why’ into something that is motivational?
Replace the Gantt chart with a one-page work breakdown structure graphic.
If you have a detailed Gantt chart, someone has gone to some trouble to understand the project. The problem with the Gantt chart is that it is too easy to get lost in the woods. Take the Gantt chart up to about the second or third level and create a graphic that looks like an organizational chart. Color in the boxes in a way that is meaningful to your team.
Distinguish between activities and tasks.
What is in a name? What we call the pieces of work that go into a project matters less than how we view those pieces of work. I like to distinguish between activities – those big work packages that make up a project, and tasks – the little things that must be done in order to reach completion on the activity.
In the work breakdown structure graphic, those boxes are the activities, and all of the little things that need to be done to accomplish those activities are your tasks. Simply documenting new tasks is not the same as adding scope.
Clearly define activities.
I wrote a blog about defining project activities last week. Understanding what each activity is all about, what ‘done’ means, what risks there are on each activity, how much effort each activity will require, and who will do the activity is essential. In a world of change, this knowledge will ground you.
Yes, the members of the team may change, scope may change, and leadership may even be in a state of flux. That’s why it is important for you to understand your project. What are you doing and why? What are you not doing? What do you know, and what do you still need to discover? Being Agile doesn’t mean being clueless. Being Agile means that you are poised to adapt.
Being Agile doesn’t mean being clueless. Being Agile means that you are poised to adapt. Click To Tweet
Are you routinely rescuing projects in chaos? I’d love to know more. Let’s chat.
