Issue link: https://industrialmanagement.epubxp.com/i/656209
march/april 2016 19 professional in charge of tracking and reporting on project progress. • Business analyst: The person in charge of collecting business requirements from stakeholders and documenting them in a way that both the programming team and business stakeholders can understand. • User experience: The professional who creates site maps and wireframes showing the navigational flows of the software. • Designer: The team member who takes the user experience site maps and wireframes and applies visual design to them. • Programmers: The people in charge of coding the software. Front-end programmers take user experience and design and create the software interface. Back-end programmers design databases that take, store and manipulate data. 2. What is this risk thing again? In regular life, when you hear the word risk, you probably expect it to mean that you might endure some harm, but in all likelihood you won't get hurt. But in software development, the term risk has a much different connotation. In The Checklist Manifesto, author Atul Gawande talks about three types of endeavors: The simple, the complicated and the complex. Software development almost always involves all three, and they are directly related to risk. First, simple project components are easy to conceptualize. A pile of snow is a good metaphor. It may be arduous to clear your driveway after a snowstorm, but there is no mystery on how to do it. You get out the shovel and dig. Second, complicated project compo- nents are hard to understand and involve a lot of steps, but if you apply both brainpower and muscle you will get the project done. A good metaphor here is assembling an Ikea Desk. It takes the ability to comprehend arcane directions with lots of steps. The whole project may run longer than expected, but with enough diligence there is an almost 100 percent certainty that the You don't know if your customization is feasible because, indeed, no one has done it before. furniture will become operational. Complex project elements, on the other hand, have a lot of variables like the complicated, but they also are highly fluid and very risky. The metaphor here is heart surgery. If you are doing heart surgery, your patient may have an unknown underlying condition. No matter how skilled the surgeon is, there is no way of knowing if the patient will get off the table. Think of software risk like a heart surgery. Every project area that has the quality of a heart surgery – diffi- culty combined with unknowns and uncertain outcome – is a risk. Diagnose the riskiness of your project by asking your project team to talk in these terms. Which project components are just a matter of sheer labor? Which are tricky (Ikea desk) but achievable? And, finally, for which parts of the project is feasi- bility itself in question? Five activities should go into your always-risky budget: 1. Integration: The need for one system to exchange data with another. It is a truism of software devel- opment that integrations can be difficult to execute and hard to debug. Integra- tions may occur with a third-party system over which you have no control. Often, integrations happen with a legacy system for which little documentation exists. Security requirements such as IP whitelisting and firewalls may be in place. Finally, integrations generally rely on network or Internet connections that may get gummed up and interrupt the flow of data. When bugs occur in integrations, it can be very hard to determine root cause. 2. Data migration: Porting data from an older system into the new one. An example of data migration occurs in the relaunch of a financial system. You need all your records from the old system transferred to the new financial system. No one wants to lose financial data. But the data from the old, legacy system may be dirty. Take this classic situation: The legacy system had a postal code field. But it had no way to validate the information's accuracy by, for example, restricting U.S. users to entering five digit numbers for zip codes. So quite often, users didn't enter legitimate postal codes. As the legacy data is analyzed, it becomes evident that the zip codes have random spaces at the end and the beginning. Sometimes people made mistakes and switched the city and zip field, entering the wrong information in each. If there are tens of thousands or hundreds of thousands of records, an automated script must be written to normalize the data. The programmer will have to think of all possibilities for correcting the freehand entry or the data migration won't work. 3. Customization: Inventing a novel feature or function. Custom- ization means writing computer code from scratch. But it can also involve changing an off-the-shelf piece of software to meet your needs better. Calling something a custom- ization suggests you are inventing something new that previously didn't exist. (A customization that has been done before, for another customer for example, doesn't count as a true customization). Customizations are, by definition, heart surgeries. You don't know if your customization is feasible because, indeed, no one has done it before. 4. Unproven technology: Employing a new/hot technology. Technology moves fast, and new ones are introduced all the time. Sometimes it's a new content management system, database technology or programming language. Think of all the apps that now exist for cell phones and tablets that did not exist even 10 years ago. Because of the drive to innovate, companies rush to employ new technologies on software projects. But just as with buying the first model year of a car, being the first adopter of a hot new technology carries risks. 5. Too-large project: Tackling a massive project in one fell swoop rather than breaking it up into parts.