Software Executive Magazine

OCTOBER/NOVEMBER 2017

Software Executive magazine helps software executives grow their businesses by showcasing the business best practices of our readers, executives from established and innovative software companies.

Issue link: http://digital.softwareexecutivemag.com/i/878720

Contents of this Issue

Navigation

Page 30 of 43

ready to get started on what is sure to be the most ef- ficient, best-quality piece of software the company has ever delivered. The inclination, especially when faced with an aggressive production schedule, is to dive right in and start coding. That is a mistake. In fact, on average, executives and teams that spend more time and effort on analysis and design end up spending less overall. They also complete projects soon- er, have fewer product defects, and are more produc- tive as teams. The old adage "Measure twice, cut once" proves true. Take sufficient time before coding begins to design and analyze the products being built. How much time is sufficient depends on the team and the project. Consider spending roughly 20 percent of any given proj- ect in analysis and design for maximum payoff. This 5th law — allowing sufficient time for design and analysis — will help lead to software development suc- cess, but executives cannot rely on it, or any one of the laws, alone. Having all the time in the world for analysis won't help a project if that project is subjected to an ag- gressive schedule with no time built in for growth. Executives who are mindful of these five laws will have a much easier time with product builds, and those who neglect these laws could face a bumpy road toward proj- ect completion. With appropriate-sized teams, sched- ules built with inevitable growth in mind, and strategies to better manage scope creep, teams that heed the laws will be prepared when high-level plans from analysis and design change as they are executed. The highest functioning teams will keep data at every step in the de- velopment process so as to better inform their estimates for the next software build. At this point the five laws will come into play again, creating a virtuous — not vi- cious — cycle of software development. S and budgets. Everyone has the best intentions at the outset of a proj- ect. Teams are optimistic, and budgets and schedules reflect that optimism. When project parameters are set, most executives are looking — as they should — at the high-level, abstract view. This view will be more accu- rate when informed with data from past performances, but it is, at best, an estimate. Once actual work begins, a project's scope increas- es. Estimates become real numbers as work is actually performed. Unforeseen but necessary parts of a build are added but they aren't accounted for in the schedule or budget, leading to problems later on. The solution is simple: Try to contain scope creep but realize that de- spite everyone's best intentions, it is inevitable. Build extra time and cost into the project from the outset. LAW 4: SMALL TEAMS ARE BETTER. When faced with a large software development project, don't put more people on it and believe that doing so will bring faster results (see Law #2). Small teams are often more capable of delivering better quality products in the same amount of time as large teams, and small teams cost less. Small teams also communicate more efficient- ly. They take less time to come to resolution when faced with decisions. In agile workflows, people are used to working in small teams. Members often know each oth- er's roles and can move fluidly through an entire proj- ect's development, further reducing cost. LAW 5: ALLOW SUFFICIENT TIME AND EFFORT FOR ANALYSIS AND DESIGN. At the beginning of any new project, the books and schedule are clean, and the staff is fresh. Everyone is MEDIAN SCHEDULE MONTHS BY STAFFING QUARTILE The above graphic is based on a study of over 2,200 completed software projects. In it, the vertical bars represent the median schedule for the smallest to largest staffing quartiles for various sized projects. Note that larger teams do not succeed in reducing schedule even though they normally represent an effort to accomplish exactly that. Schedule Duration (Months) 12 0 2 4 6 8 10 ≤ 100 501-1000 301-500 201-300 101-200 > 1000 Smallest Quartile 2nd Quartile 3rd Quartile Largest Quartile 31 SOFTWAREEXECUTIVEMAG.COM OCTOBER/NOVEMBER 2017

Articles in this issue

Links on this page

Archives of this issue

view archives of Software Executive Magazine - OCTOBER/NOVEMBER 2017