Industrial Management

MAR-APR 2016

Issue link: https://industrialmanagement.epubxp.com/i/656209

Contents of this Issue

Navigation

Page 19 of 31

20 Industrial Management The size of your project is directly related to how risky it is. Generally speaking, the larger the project, the greater the risk. Many business stakeholders believe they have no choice in the size of the project they are undertaking. However, business managers generally have far more flexibility than they think. Even a large project can be broken down into smaller pieces. For example, perhaps a company's entire corporate website needs to be redone. It is possible to take a piece of the website, say the investor area, and launch that first, then move on to the next part. It may be a little messy to have one piece of your site looking different from another. But rest assured that being over budget and late is far messier. What you can do: Understand the most common project risks. Account for them in timeline and budget. First, get the definition straight. Software development risks have a high likelihood of impacting budget and timeline. One of my most popular aphorisms is, "Optimism is not your friend in software development." When you or your team start to say, "It'll probably all work out," stop yourself. Risks in software most likely will have consequences. Next, learn to identify risks in your projects. The five biggies above cover most matters but not everything. Diagnose your own project by learning to spot heart surgeries. One good hint is to learn how and when to unlisten to programmers and other techies on your project. Often their language can be misleading. They can make risky, heart surgery tasks sound benign: "We'll just write some custom scripts to normalize the data. It'll be no problem." Watch out for words like "just" and phrases like "no problem." Also, set aside a contingency. For every risk you take on, some percentage of the budget should be set aside for contingency. I always assign a 15 percent contingency to a large project. For integrations, I count 5 percent for each. This results in a dollar cost value for One good hint is to learn how and when to unlisten to programmers and other techies on your project. each risk the business accepts. You won't be surprised to learn that when risks are quantified in this way, the conversation shifts. "Do we really need to use that new, hot technology?" Or, "How hard would it be to break up the project into smaller pieces?" An important note before leaving the subject of risk: The very reason you may be undertaking a software project may be to do something no one has done before (customization). Further, data migrations and integrations are realities of modern software development. Large projects sometimes have to happen. No one is saying the five big risks should be avoided at all costs. Rather, we are saying that risks, when they are present, should be recognized and treated with the appropriate degree of seriousness. 3. Some budgets are more accurate than others There are four methods of budgeting in software development: 1. Comparative budgeting: When a team uses a recently completed equiv- alent project to estimate a new project 2. Bottom-up budgeting: When a detailed list of tasks exists and can be estimated one by one 3. Top-down budgeting: Where few equivalencies can be identified and it is not practical to develop a detailed list. The team estimates big "buckets" and how long they will take. 4. Blends: A budget that involves two or more of the above The most important factor in comparative budgeting is that team members have hands-on experience with something similar to what is being requested. In the real world, comparative budgeting happens a lot in software development shops where the team does the same kind of project over and over for different customers. There is absolutely nothing wrong with this strategy. It works, and everyone gets a fair shake. The key elements to success are a relatively small project ($150,000 is probably the limit if the projects are very similar); a well- understood kind of product, such as a website with common features; and the ability of the software team to equate the requested project accurately with another recently completed project. For bottom-up budgeting, say your sales team has a list of feature requests for the e-commerce site your customers use to order product. With this list of 20 improvements, they are convinced lead-times will shorten and sales will increase. The software team estimates the list one by one, and that is used to create the budget. This bottom-up budgeting is the most reliable of the methods. Where bottom-up budgets can be created, it's great. But be cautious. Everyone knows, intuitively or by experience, that bottom-up budgets are the most reliable, so project leadership may try to force bottom-up budgeting where it is not possible. A strict waterfall approach demands all tasks to be estimated in detail. But such a list can take months (or even years) to generate, as large swaths of business requirements must be understood down to the atomic level. Modern project management best practices recommend including more agile methodologies. While it is useful to bottom-up budget where you can, applying this method inappropriately can lead to project rigidity as well as delay. Top-down budgeting is often applied when no ready equivalency exists, when innovation is required and where it is impractical to generate a detailed list. An experienced software team looks at the business requirements and estimates large buckets of the project. They have detailed discussions and come up with a best guess as to how long the project will take. Top-down budgeting usually has some role in costing most midsized to large software projects. In most larger software projects, there will be a signif- icant number of unique requirements, lack of full lists and other unknowns. What you can do: Understand how the budgeting methods work. In

Articles in this issue

Archives of this issue

view archives of Industrial Management - MAR-APR 2016
loading...
Industrial Management
Remember me