Guest post: Troy Magennis of Focused Objective
As long-time IT professionals ourselves, we at Planview AgilePlace understand the pain of being asked for detailed estimates about things we’ve never done and may never do. An awful lot of time gets wasted building detailed plans that end up bearing no relation to reality. The idea of making people sit through boring status meetings to give percent-complete estimates for mostly irrelevant project plan line items makes us kind of ill. So, we whole-heartedly support the drive in the Lean-Agile world to move away from detailed plans and estimates at the tactical level. We think the capability metrics you can get from a well designed Kanban system are much more useful for short-term forecasting. Hint, hint.
But …
Executives making investment decisions need some sense of where a big project might head before they can responsibly give the green light to start buying equipment and licenses, hiring staff, in some cases leasing buildings, etc. A senior IT-exec friend of ours described his business peers asking the question “What cliff are you driving us toward?” At this level, estimating is critically necessary.
Our friend Troy Magennis is of the same mind. Troy is a long time associate of David Anderson, Dan Vacanti, and other key folks in the Kanban movement. Present at the creation you might say. He was a senior technical leader for Travelocity – a very big and admirably Agile corporate software development company. He’s now written a very interesting book about the need for effective forecasting to support Agile at Scale. And he’s building some awesome executive estimating tools that we are eagerly anticipating.
His essay is a must-read for Agilists who are serious about growing the movement.
————
Agilists must accept the need for revenue and budget forecasts to be taken seriously
It is easy to join the chorus of opinion that software project estimation is waste and must be eliminated. Whilst I can understand the objections to spending valuable time preparing and rationalizing a set of estimates for ill-defined features or projects, this posting explains the counter-points – why estimation is necessary, and why it is in your best interest to participate.
I’m not defending the obvious waste of being asked to estimate work that is going to proceed regardless of the time and cost taken to complete; there is little rational reason to waste time putting together these estimates. I am saying that most companies will require some form of estimates from IT in order to grow and be competitive. This post considers two basic causes for companies to require estimation –
- Choosing the right portfolio of projects, and setting next year’s revenue targets.
- Planning and hiring staff for the future, and setting next year’s cost targets.
Portfolio Selection and Revenue Targets
A business is often confronted with multiple project and feature ideas. People on the product and marketing side propose many ideas and scramble to get their ideas promoted higher in the portfolio by escalating the revenue estimate for each feature (and yes, the product and marketing people also hate giving a revenue estimates in writing, but they have to as well). A committee or an individual then filters through this massive list and determines what products and features give the best return on investment, leading to a target for the following year’s revenue expectation. Around this time period is where there are numerous drive-by interruptions in the development area by people lobbying for “How long would it take to build x” estimates (where x is a single line description of a complex feature).
If you have ever participated in the “Budgeting Olympics” carried out each year in medium to large companies, you know it is brutal, competitive, political, and frustrating process. It’s hard to defend the eventual accuracy of this adventure, but rather than pout, I’m going to propose this time is where IT management needs to step up and be available and willing to help. IT needs to set correct expectations and offer options to the business on what projects can be delivered, and what staff will be required to fulfill these dreams and aspirations of the company’s revenue targets. Sitting out this process merely leads to IT being signed up to poorly considered project delivery dates, and the inability to show the balance of additional, and business as usual staffing levels for operational and maintenance tasks. All too often it is incorrectly assumed that all IT staff are available for new project work, with comments being phrased “you have 400 people and you are telling me you can’t do x!”
The portfolio and budget outputs required for the business to make promises with some certainty are –
- A revenue target for the company next year.
- An idea of when each portfolio project will start earning revenue.
- The number of total staff to calculate the people cost.
You might feel that IT estimates are necessary just for 2 and 3 above, but in actual fact, it is the first output (revenue target) that is the significant driver. A product delivered in March will earn revenue from April through to December, a full nine months. A product delivered in November earns one month of revenue. This means that in order for the business to make public (or to show internal and external investors) a plan for growth over the next period, an understanding of when a feature starts earning revenue is pivotal. Enter the software project delivery date estimate.
At the moment, our “Agile” and “Lean” methodologies make it difficult to give clarity and certainty around the answers necessary. This is often a cause of friction between those trying to prepare a portfolio/budget, and those in IT trying to deliver quality products (value) at regular intervals, but with ambiguous calendar dates for any individual feature (all forms of Agile development). In order for the business to understand revenue impact of each feature/product there must be some precision on go-live dates. Confronting this need with what appears to be an excuse of “we are agile” leaves the executive management frustrated and disillusioned with IT. We need to work with the business to choose the right projects, give them indication when a feature will be revenue-ready, and clearly express the risks and likelihoods of hitting those dates. This means enthusiastically working with them on scope selection, and providing delivery date estimates as early as possible. We also need to work with them on staffing plans and costs which we cover now.
Appropriate and Necessary Staffing Decisions
Funding a project or feature of a product is often the first step or an annually occurring task carried out in most organizations. Building software takes people, and these people cost money. Understanding how many individuals, and what skills those people need is a key IT management task, and there is no single correct formula. Adding more people may reduce the time to market (or may not if added at the wrong time or people with the wrong skills), but how much shorter? And even if we did deliver earlier, would there be more revenue recognized over the course the year or reporting period? All of these questions require an understanding of how much work is required on a project, and how many people for each delivery scenario AND maintain the current products delivering value.
Unless you are re-using a current team, AND the people putting the money into the project are happy to accept the risk of not-knowing the go-live calendar date, AND are supportive that it will be delivered at the first possible moment – you can’t skip estimation. If you do, you are likely to require emergency staffing additions throughout the project in order to hit an arbitrary target date decreed by somebody unskilled in software development. It may not always be apparent, but participating early, ensuring that any target date has your input and blessing, and that you staff a project team to succeed hitting that date is by far the least stress and workload overall.
Executive management loses faith in IT every time someone has to make emergency staff hire or scope-cut to get a project back “on track.” The only solution is to make sure that the tradeoffs and expectations are set early, and those on the business side participated in balancing cost (people) versus revenue targets early, ideally during the portfolio and budgeting process before the project starts. You want the product and marketing teams to be on your side when asking for more staff; it is very powerful when the business, not just IT management go asking for more staff to consolidate a revenue target (by delivering on-time or earlier), and this is the only defense against the “IT asking for more and more staff” opinion spiral.
Having the ability to build and articulate the staffing resource options for an IT portfolio of new work and the staff required for business as usual operations is key to rebuilding the business executives trust of IT management. Proposing options for increasing staff strategically to help a company hit or exceed its revenue plans returns IT management the hero status we deserve, as opposed to the geek cowboys from the second floor we often get labeled now.
Summary
In a future posting I’ll summarize the strategies on how to build and communicate software estimates, for both date and staff forecasting, and how to minimize the time and disruption to IT whilst assisting the business throughout the budgeting process. This material is pulled from my book Forecasting and Simulating Software Development Projects – Effective Modeling of Kanban and Scrum Projects using Monte-carlo Simulation. I’ve been positioned to see both sides of the estimation argument, and have built tools and written about ways to quickly and reliably model software projects (you can find more at FocusedObjective.com).
I would love to live in a world that didn’t require software project estimates at all, I just don’t believe it exists in all but the smallest projects and ventures. Being skilled in why estimates are necessary and how to work with your business peers in offering solutions and opinion early during the portfolio and budgeting phase is the best way to change the executive management’s opinion of IT managers, returning IT to the hero status it so richly deserves.
About the author
Troy is an experienced executive who has been involved in many leading software organizations over 20 years. Most recently, Troy founded Focused Objective to build tools and training for simulating and forecasting software development projects, including the Monte-carlo techniques as described in his book Forecasting and Simulating Software Development Projects – Effective modeling of Kanban and Scrum projects using Monte-carlo simulation. You can follow Troy on Twitter at @AgileSimulation or contact him by e-mail at [email protected].
