At one point in my career I had a team of over 50 project managers working on over 200 different projects of various sizes. Additionally I had oversight for about twice as many contractors. One of the leadership challenges I had was providing consistent direction among all the diverse styles, situations, and types of projects that we dealt with on a daily basis. On any given day I found myself getting bogged down in the quagmire of people advocating for different types of approaches that their specific project called for.
Like many executives, I was also bombarded by cold-calls from high-priced consultants pitching training programs and the latest technology platforms designed to help “transform” my project management team. In the midst of this seemingly daily chaos, I was confounded by the idea that things should be simpler. Intuitively it felt like we were always creating unnecessary complexity.
One day, fed up with it all, I sat in my office reviewing the list of all of our projects and started thinking. I asked myself: “Why do some projects succeed and others fail?” and “Are there common factors that contribute to the success or failure of projects?”
I made it my personal mission to find answers to these questions and began sitting in A LOT of project review meetings. I spent many hours observing project teams and asking tough questions. I cross referenced industry benchmarks, I read through all the common project management reference guides, and I compared it to what people were doing on our projects. Here is what I learned:
1. Most people fake it to make it. Approximately 50% of the teams who claimed to be using a specific project methodology were not actually using it. When I requested examples of artifacts that their methodology required, they often couldn’t produce them. Some teams used “agile methodology” as an excuse to do whatever they wanted and other teams used “waterfall ” as an excuse to be slow or to de-prioritize dependencies with other teams. Still others flat out stated that their project sponsors didn’t require a methodology because it was just a bunch of “busy work.”
2.There was no common language or culture associated with the different project managers. Expectations of what was required from a project professional varied wildly based on where people previously worked, went to school, or which organization they worked in. Even with training and PMP certifications, there was no consistent idea of what “good” looked like.
3. The teams that worked best together had regular meetings, commonly understood goals, clear measures, and open lines of communication. It didn’t matter what project method they used because they always just “worked it out together.”
Equipped with these insights I was empowered to take action. However, as many business leaders know, it’s incredibly difficult to make large changes in mature organizations. Even if you do, the resources to execute can be complex, costly, and produce mixed results. Behavior change at scale require focus and simplicity.
And there’s the Catch-22 with fancy methodology training programs and sophisticated project management technology platforms. They may technically be “good”, but they’re often ineffective to implement. And by the time something gets implemented, there will be some new approach that someone perceives as better for their team or organization.
The basketball player Michael Jordan famously said: “The minute you get away from fundamentals – whether it’s proper technique, work ethic or mental preparation – the bottom can fall out of your game, your schoolwork, your job, or whatever you’re doing.” He is absolutely correct. With that in mind, instead of turning to consultants for help, I put together an “All Star” team of our best project managers to collectively identify the primary tools for project success that we would all use – the fundamentals that really mattered. This was easier said than done, since everyone held strong opinions. However, after healthy debate, we identified “10 tools” every project needed.
We refined them, printed them on a sheet of paper, shared good examples, trained for them, and set the expectation that people would be held accountable. We thought of these as tools that every project manager should use.
The checklist is as follows:
- A project charter with defined scope or prioritized list of deliverables.
- Measurable success criteria.
- A project organization model that shows roles, responsibilities, and reporting relationships.
- A decision making process for the project team to approve changes to scope, budget, and staffing.
- A minimum weekly leadership update to communicate project status.
- A declared project management methodology to manage the work with the expectation that the team could produce artifacts.
- A project plan, based on the declared methodology, that highlights when deliverables are due.
- A budget management process that shows overall budget and status against it.
- A communication plan to manage change with the internal organization and/or external customers.
- An issue tracking list with owners and dates assigned to resolve them.
That was it. 10 “tools” distilled down to approximately 120 words. Accountability was easy, because anyone could audit a project with the 10 item checklist. The expectations were so basic that they could be applied to almost any project management methodology. These were the “10 Tools” that we expected every project manager to have in their toolbox. They were the bare minimum. It was up to them to determine the best way to use them for their situation, and what additional tools or approaches they might add.
A brief video overview of this topic is highlighted below