Issue link: https://industrialmanagement.epubxp.com/i/656209
march/april 2016 21 a common scenario, a businessperson has a project that is blowing timeline and budget. He says, "I did a software project last year, and it came in on time and on budget. What is wrong with you people?" This person may not understand his previous project was comparison- budgeted against a very similar project. The current project requires top-down budgeting. The budget, by definition, is far less likely to be accurate. Avoid this scenario by knowing which sort of budgeting is used in creating your estimates. Understand the accuracy of each and set aside contingencies for the less accurate methods. Know when and where to apply each method. In general: • Use comparative budgeting where equivalencies exist on small to medium-sized projects or project components. • Generate lists where possible for bottom-up budgets. • Use top-down methods for large projects with innovation. 4. Hey, businessperson, don't shy away In the beginning of a software project, it is critical that everyone understands what is included in their role and what is not. As a general principle, business stakeholders are often unaware of their responsibilities and therefore shirk them. Team implementers, in contrast, often overreach. Here's a good rule: Business stake- holders get to decide, and the project team gets to recommend. More specifi- cally, the business leadership makes decisions upon matters of technological strategy, while the implementation team makes decisions upon tactics, the "how." A useful analogy would be a child undergoing elective surgery. Of the two options, the surgeon wants Option A, while the parents prefer Option B. No matter how strongly the surgeon feels (she may even decline to do the procedure), the decision belongs to the parents. Once in the operating theater, It's the responsibility of the project leadership to make sure the business stakeholders have all the information they need to make strategic decisions. the surgeon determines how to perform the procedure or deal with unforeseen things that come up. Keep this analogy in mind with software development. One point of discomfort in the previous example is that the doctor possesses all the specialized knowledge. Who are the parents to decide? They didn't go to medical school. Of course, such a question is ridiculous. They get to decide because it's their child. Sometimes programmers and other techies similarly wail, "How can they decide? They don't even know what they're talking about." They then leap into making strategic technological decisions without even realizing that these decisions are not theirs to make. They may say things like, "The database must be replaced." Or, "Our new content management system is going to be Drupal." Programmers must be educated by experienced managers that their job is to recommend, not to decide. Techies must learn to recognize when a strategic issue comes up and say, "We came across this thing, and I think it involves a business decision," thus elevating the question to leadership. Of course, driving outside her lane may not be the techie's fault. It may be a business stakeholder who's pushing her there. Business leaders with little experience in technology often raise their palms to the sky and say: "I don't know? What should we do?" The techies leap in and take the reins. Many organizations get into enormous amounts of trouble and expense because strategic technology decisions are being made by midlevel programmers who have no insight into any of the organization's actual strategy. Business leaders end up discovering too late that their customer database is a mess or that they are in violation of federal data-protection guidelines. What you can do: Step up. It's the responsibility of the project leadership to make sure the business stakeholders have all the information they need to make strategic decisions. Then the business stakeholders must step up to their responsibilities. It is critical for organizational leadership to accept that however unprepared they may feel, they are the strategic decision-makers in this project. One of the things most fatal to the software development process is when the business leadership abdicates its responsibility due to a lack of confi- dence. Projects dissolve into debate and chaos. With support and determination, nontechnologists can make good technology decisions without formal training. There are tools that can help that process along. First, have a trusted technology partner. This may be your existing CIO or a consultant. Think of choosing this person as you would a medical specialist. How would you select an orthopedic surgeon? You would talk to colleagues, do research, identify candidates and look at success rates. Then you would look in the whites of that person's eyes and decide if you trust him or her. In addition: • Do your homework. Buy a "For Dummies" book on databases or read a TechCrunch article about Ruby on Rails. You can meet your tech partner halfway by understanding the basics. • Get information from the project team. Good communication from the project team needs to flow up to leadership. Business leadership can insist on regular reports and check- ins. • Accept your role. Like the parents in the earlier analogy, you as business leadership are on the hook for the major decisions. However unprepared you may feel, you must get the proper information and make the call. The good news is that I have seen dozens of nontechnologist business leaders with absolutely no computer background make very sophisticated and quite accurate technology decisions just by doing their homework and listening carefully. v