If you work on a well-oiled execution team that can estimate, plan, and deliver the right results at the right time, most of the time, then congratulations, you don’t need to read any further. Go back to your charmed life (We are sure you are not self-delusional).
For the rest of us, executing technology projects – especially complex custom software development – in a new environment with a new team is inherently non-predictable. Teams take a while to gel, some teams never gel. Critical scope items are often discovered midway through the project, which drive additional cost and duration . Trimming scope is like eating kale. You know it’s good for you, but you toss it in salads or juices in a masked form, and rarely want to eat it straight . Yet executive management often requires a well-articulated scope, budget and duration in order to approve the project. It’s a catch-22. So what to do?
Planning or assessment phases often present a false precision for the expected outcome, and executives and consulting partners are often incentivized to get things started quickly to meet strategic goals and sales quotas. Let’s face it: an executive communicating uncertainty to her board or a consultancy doing the same to its partner is a quick ticket to a lower pay scale or out the door. Instead of having the honest, but difficult conversation about unknowns, it’s far less risky, and unfortunately more common, to express the utmost confidence, get approval, and move on.
When uncertainty rears its ugly head, fingers start pointing in every direction. Oftentimes the project delivery team is left holding the bag and must sacrifice quality to validate the false precision handed down from the assessment phase. Once you’ve headed down this path, the best you can hope for is that the only quality sacrificed is the quality of life of your people. You’ll accrue a costly morale debt for the organization , but if you’re lucky, you can manage attrition and offer rewards after the fact to show your gratitude.
Perhaps even more dangerous than incurring morale debt is sacrificing the quality of your product to meet a deadline. In the age of social media and the mobile, always-connected consumer, pushing a half-baked product to market can, and will, damage your brand before you have time to tweet “I’m sorry”. The same dynamic applies to the tools and services you buy, build, and maintain for your employees. They hold you to the same high standard as your customers.
But enough doom and gloom, what are some solutions?
Unfortunately, if you’ve found yourself at the helm of a current project already doomed by unrealistic expectations and false precision baked in from the start, your options fall into two buckets: “Rub Some Dirt On It” or “Call a Timeout”.
“Rub Some Dirt On It”
Power through and manage morale and stakeholders the best you can. Occasionally, you can dream about better projects and greener pastures, but for the next six months you are sucking it up and building character. The blood will clot and the scars will heal. Never fear, a new internet meme will make you feel good about learning more from failure than success.
“Call a Timeout”
If the game is getting out of control and you fear you are setting your team up to lose, stop, take a breath, and assess. What’s going wrong? Don’t wait for the coroner’s call to perform the dreaded post-mortem. Get to the root problems (there may be more than one) and adjust accordingly. Take a page out of Brooks’ playbook, 40 years young this year, and don’t solve the problem by piling on more estimates and more false certainty. The wisdom in the Mythical Man Month has withstood the test of time. I quote “Until estimating is on a sounder basis, individual managers will need to stiffen their backbones and defend their estimates with the assurance that their poor hunches are better than wish-derived estimates.” (http://www.cs.virginia.edu/~evans/greatworks/mythical.pdf)
To truly achieve superior experiences for your team, partner, and customer, however, the solution needs to happen at project inception. Executives and consulting partners need to be vulnerable and admit their ability to precisely predict and control large and complex outcomes is a 50/50 proposition at best. Transparency feels like a modern trend, but Brooks recommended substituting transparency for questionable estimation techniques back in 1975, writing “We need to develop and publicize productivity figures, bug-incidence figures… and so on”.
Finally, ensure that your organization doesn’t reward big projects just for being big. If promotions and influence are driven by project headcount and budget, your leaders will seek bigger teams and bigger budgets, stacking the deck against their chances of success from the start. Don’t take my word for it. A Gartner survey found that IT projects with budgets exceeding $1 million were nearly 50% more likely to fail than projects with budgets under $350,000. (http://thisiswhatgoodlookslike.com/2012/06/10/gartner-survey-shows-why-projects-fail)
Starting small and recalibrating an outcome trajectory based on thinner slices is a better way to plan a larger effort. You’ll be able to generate real velocity data about your team and execution environment more easily. If you can feed your team with 2 pizzas (http://www.businessinsider.com/jeff-bezos-two-pizza-rule-for-productive-meetings-2013-10) you’ll change the equation from “more communication” to “effective communication”. Lastly, designing for small, decentralized teams will allow them to move faster, creating a virtuous feedback loop that reinforces the core activity of software development, namely, knowledge discovery. (http://cacm.acm.org/magazines/2013/1/158762-how-we-build-things/abstract)
Don’t roll the dice on your next project. Have the courage to start small, measure and publish velocity, and be transparent.
For another take on how Pariveda sees small teams, read Mike Strange’s post on “Putting the SWAT back in Teams” https://www.linkedin.com/pulse/putting-swat-back-teams-michael-strange?trk=v-feed
Or dive deeper on Pariveda Points of View on a range of Business of IT topics: http://www.parivedasolutions.com/Perspective/Points-of-View/Pages/default.aspx
Contact the authors: Brian Duperrouzel and Jack Warner
