I’ve been pulled into many emergency war rooms to kickoff last-ditch efforts to save failing projects. It’s heartbreaking to watch. Leaders in the room try hard to believe there’s hope to remedy the crisis. They sell a “great opportunity” to those tasked to fight the enemy. The technical team looks around in disbelief…they’ll have to endure another death march. The team’s reluctant to ask the hard questions such as “why is Q1 a hard deadline?”. The product management team crosses their fingers behind their backs with a barely genuine smile on their face. Racing through all of their minds is the question: Will I miss my kids birthday again this year? The pressure is on, the scope’s been determined…oh, and here’s your date, go!!
What’s the problem?
If you’ve ever solved a complicated puzzle before, try solving one at gunpoint. As you might imagine it doesn’t go well. Your fight-or-flight response kicks in and creative thinking sits in the backseat next to extreme nervousness and your résumé. For more reading on why solving puzzles under a lot of pressure to perform, see Glucksberg and the candle problem.
How did you get here?
Organizations that are struggling, or even dying, make terrible decisions in attempt to save themselves. Rather than pause, address the root issue, fix it, and improve, they throw more gasoline on the fire. They really think more people and more pressure will do the trick. For those that still hold on to this idea, the one that more people will fix your late project problems, Brooks Law applies and we’ve known this doesn’t work since the 1970’s.
This scenario plays out often with agile adoptions gone wrong. There is a myth in the world of software development that by being ‘agile’ you get the same work done faster. Another myth is you can apply a new software delivery framework superimposed on top of your old SDLC. Now, If you’re no more nimble now than you were before, are you really agile? Did doing ‘Agile’ make you more agile? I didn’t think so. Applying more pressure won’t help your condition. We’ll need to look deeper.
What can you do now?
Before you rush into the next death march, slow down a little and learn. Ask lots of questions like: “why are you where you are?”, “What are the real constraints?”, and “What’s the real problem?.” My favorite analogy in this case is: you have to stop the car to change a flat tire. If you have an educational flat tire, fix it first, then build an organizational habit of learning. Take this advice and begin to speed along faster than before.
Are you new to data warehousing? Take a class and work with a strong mentor or consultant as you get ramped up on your critical project. Are you new to Scrum, LeSS or SAFe? Take a proper training and get really good coaching to help navigate the grey areas you don’t learn in class. We in the technology space grossly underestimate how hard our work is, how hard coordination of many people against a large product offering can be. A medical analogy, we need to really understand the principles and practices of brain surgery before we have our first trauma patient. Do you really think large scale software development efforts are less complicated than brain surgery?
One last point
You have to slow down and educate yourself before you’re in a crisis. No one’s going to have a lessons-learned discussion or take proactive steps to fill in educational gaps when the house is on fire. They’re just going to put out the fire. Its like groundhog day…over and over organizations are just putting out the next project fire. Please, please stop setting projects on fire.
originally posted on Responsive Advisors
The Gospel According to Robb 