Getting Projects to Deliver Results

The conversation started over coffee with a friend who works at a European company that's been around for over 300 years. She was explaining the challenge of modernizing their web development team. The crux of the discussion went something like this:

"I've got a web design team that's running agile with a prioritized backlog, daily stand-up meetings, and 24-hr turnarounds. Then I've got to connect with an IT team that's running a traditional waterfall methodology for our back-end financial services. They have 1-2 month turnarounds. It's just not working and training isn't helping. Any thoughts on how to resolve this?"

I just laughed (this was not the response she hoped for). Her question brought back a flood of memories from my time leading the enterprise Project Management Office at a Fortune 100 company. We had over 300 active projects in the portfolio at any given time, and I encountered the same types of problems my friend described. No doubt, the Agile vs. Waterfall debate is ongoing. However, I explained, I thought her focus on Agile vs. Waterfall was misplaced.

Having helped her through her challenge, I thought it worthwhile to share some insights with the intent of helping other business leaders maximize the performance of their project teams.

"These Are Not the Droids You're Looking For"

First things first. Don't get distracted by the "Jedi mind trick" of methodology-speak. I constantly heard debates from teams advocating agile, waterfall, iterative, stage gates, SCRUM, PMI certifications, change management methodologies, and so forth. Like many executives, I was also bombarded by cold-calls from high-priced consultants pitching training programs or the latest technology platform to help manage projects. Yet I was frustrated by the fact that methodologies and platforms never accounted for the challenges experienced in "real life".

One day, fed up with it all, I sat in my office reviewing the project portfolio and started thinking. I asked myself: "Why do some projects succeed, and others fail?" and "Are there common factors that contribute to success across the ‘good’ projects?"

I made it my personal mission to address these questions and began sitting in A LOT of project review meetings. I encountered a variety of examples where project teams, running different methodologies, were working together and delivering incredible results. I also encountered examples where less complex projects were performing poorly. Thus, I concluded, we probably weren't dealing with an "incompatible methodology" crisis.

Three Important Insights

After asking various teams some tough questions, reviewing my findings against industry benchmarks, and comparing the data in the portfolio, here is what I learned:

1. Approximately 50% of the teams who claimed to be using a specific methodology were faking it. When I requested examples of artifacts that their methodology required, they often couldn't produce them. Some teams used "agile" 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, and following one was just a bunch of "busy work", anyway.
   
2. The teams that worked best together had regular meetings, commonly understood goals, deep familiarity with their products, and open lines of communication. It didn't matter if they had different methodologies because they always just "worked it out together."
   
3. Problems in the back-office often reflected problems in the front office. When projects spanned multiple business teams that had differing priorities for the work, this often created issues with how the project teams operated. It was like a modern day Romeo & Juliet, where the children got caught up in the feud between their families.

Insights Are Nice – But Only Execution Matters

Insights don't matter if you don't take action. However, as many business leaders know, it's incredibly difficult to make broad sweeping changes in mature organizations. Even if you do, the resources to execute can be complex, costly, and produce mixed results. Behavior change at scale requires focus and simplicity.

And there's the Catch-22 with methodology training programs and sophisticated project management platforms. Yes, it may technically be "right", but it's often ineffective to implement. And by the time it does get implemented there will be some new approach that's perceived as better. That is why cold-calling consultants always bill hourly.

So, What Do You Do?

The "All Star" 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. Instead of turning to consultants for help, I brought together a team of "All Star" project managers to get help defining the key factors for project success – the fundamentals that really mattered. This was easier said than done, since there were quite a few "methodology zealots" in the room. However, after healthy debate, we identified "10 things" 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. Accountability was easy, because anyone could audit a project with one piece of paper and check boxes next to each of the 10 items.

What we ended up with was so straightforward and "jargon-free" that folks from every part of the business understood it.

The 10 Fundamentals

Every single project, regardless of methodology, was expected to have the following items in place:

1. Documented scope with a prioritized list of deliverables
   
2. Measurable success criteria
   
3. A project organization model that shows roles, responsibilities, and reporting relationships
   
4. A decision making process for the project team to approve changes to scope, budget, and staffing
   
5. Weekly leadership updates from the project manager to communicate project status
   
6. A declared project management methodology to manage the work with the expectation that the team could produce artifacts
   
7. A project plan, based on the declared methodology, that highlights when deliverables are due
   
8. A budget management process that shows overall budget and status against it
   
9. A communication plan to manage change with the internal organization and/or external customers
   
10. An issue tracking list with owners and dates assigned to resolve them

That was it. Clear expectations condensed down to approximately 130 words.

The Finer Points of Ballroom Dancing

Now, back to my friend with the web development team. After explaining all this I knew she still wouldn't be satisfied. So, with the fundamentals established, I revisited her original question, which was: "How can I get Agile and Waterfall teams to work together?" I explained it like this:

Once the fundamentals are in place, the finer points of getting project teams to work together is sort of like ballroom dancing. Establish the lead partner and let them set the pace, keeping in mind the unique abilities of the other dancer. For example, if the lead project team is using waterfall, they set the schedule. Then the agile team should establish sprints focused on each required deliverable in the context of the waterfall plan. Or, if it's the other way around, have the waterfall team explore "compressed" project plans that focus on a single deliverable for the agile team. It may require a bit of give and take from each partner, however, with the fundamentals in place they'll be able to make it work. Sort of like on the reality TV show, "Dancing with the Stars".

Summary

Whether you're leading a large scale portfolio of projects or simply trying to improve performance for an individual effort, I hope you find these "10 fundamentals" helpful.

As always, please join in the discussion. We would love to hear about other approaches that have worked for you or your project teams.

[eventpdf]