![\"\"](\"https:\/\/blog.planview.com\/wp-content\/uploads\/2020\/02\/All-elimination-is-waste.jpg\")
<\/h3>\n<\/h3>\nAs long-time IT professionals ourselves, we at Planview AgilePlace understand the pain of being asked for detailed estimates about things we\u2019ve 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\u00a0move away from detailed plans and estimates<\/strong>\u00a0at the tactical level. We think the capability metrics you can get from a well designed\u00a0Kanban system<\/a>\u00a0are much more useful for short-term forecasting. Hint, hint.<\/p>\n But \u2026<\/p>\n 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 \u201cWhat cliff are you driving us toward?\u201d At this level, estimating is critically necessary.<\/p>\n 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 \u2013 a very big and admirably\u00a0Agile corporate software development<\/a>\u00a0company. He\u2019s now written a very interesting book about the need for effective forecasting to support Agile at Scale. And he\u2019s building some awesome executive estimating tools that we are eagerly anticipating.<\/p>\n His essay is a must-read for Agilists who are serious about growing the movement.<\/p>\n \u2014\u2014\u2014\u2014<\/p>\n 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 \u2013 why estimation is necessary, and why it is in your best interest to participate.<\/p>\n I\u2019m 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 \u2013<\/p>\n 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\u2019s revenue expectation. Around this time period is where there are numerous drive-by interruptions in the development area by people lobbying for \u201cHow long would it take to build x\u201d estimates (where x is a single line description of a complex feature).<\/p>\n If you have ever participated in the \u201cBudgeting Olympics\u201d carried out each year in medium to large companies, you know it is brutal, competitive, political, and frustrating process. It\u2019s hard to defend the eventual accuracy of this adventure, but rather than pout, I\u2019m 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\u00a0what projects can be delivered<\/strong>, and\u00a0what staff will be required<\/strong>\u00a0to fulfill these dreams and aspirations of the company\u2019s 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 \u201cyou have 400 people and you are telling me you can\u2019t do x!\u201d<\/p>\n The\u00a0portfolio and budget outputs<\/a>\u00a0required for the business to make promises with some certainty are \u2013<\/p>\n 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.<\/p>\n At the moment, our \u201cAgile\u201d and \u201cLean\u201d 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\u00a0Agile development<\/a>). 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 \u201cwe are agile\u201d leaves the executive management frustrated and disillusioned with IT.\u00a0 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.<\/p>\n 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.<\/p>\n 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 \u2013 you can\u2019t 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.<\/p>\n Executive management loses faith in IT every time someone has to make emergency staff hire or scope-cut to get a project back \u201con track.\u201d The only solution is to\u00a0make sure that the tradeoffs and expectations are set early<\/strong>, 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 \u201cIT asking for more and more staff\u201d opinion spiral.<\/p>\n 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.<\/p>\n In a future posting I\u2019ll 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\u00a0Forecasting and Simulating Software Development Projects \u2013 Effective Modeling of Kanban and Scrum Projects using Monte-carlo Simulation<\/em><\/a>. I\u2019ve 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\u00a0FocusedObjective.com).<\/p>\n I would love to live in a world that didn\u2019t require software project estimates at all, I just don\u2019t 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\u2019s opinion of IT managers, returning IT to the hero status it so richly deserves.<\/p>\n <\/p>\n About the author<\/strong><\/p>\n Troy is an experienced executive who has been involved in many leading software organizations over 20 years. Most recently, Troy founded\u00a0Focused Objective\u00a0to build tools and training for simulating and forecasting software development projects, including the Monte-carlo techniques as described in his book\u00a0Forecasting and Simulating Software Development Projects \u2013 Effective modeling of Kanban and Scrum projects using Monte-carlo simulation<\/a>. You can follow Troy on Twitter at\u00a0@AgileSimulation<\/a>\u00a0or contact him by e-mail at\u00a0\u00a0troy.magennis@focusedobjective.com.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":" 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\u2019ve 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…<\/p>\n","protected":false},"author":127,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_editorskit_title_hidden":false,"_editorskit_reading_time":0,"_editorskit_is_block_options_detached":false,"_editorskit_block_options_position":"{}","footnotes":""},"categories":[38],"tags":[511],"class_list":["post-12433","post","type-post","status-publish","format-standard","hentry","category-work-collaboration","tag-leankit"],"acf":[],"yoast_head":"\nAgilists must accept the need for revenue and budget forecasts to be taken seriously<\/h3>\n
\n
<\/div>\nPortfolio Selection and Revenue Targets<\/h3>\n
\n
Appropriate and Necessary Staffing Decisions<\/h3>\n
Summary<\/h3>\n