According to market research, over 50% of outsourced development projects fail, and over 70% of stakeholders report a negative experience. Why would an outsourcing company post those statistics?
Let’s refocus this: about 50% of outsourced development projects succeed and around 30% of stakeholders report positive experiences. How do you become the 30% of projects that succeed? The answer resides in “processes”.
The common conception of software development has taken on the unfortunate image of highly-talented, slightly eccentric developers cranking out the next Facebook or Twitter at midnight while drinking tons of Mountain Dew. That’s the 70%. You can find them lining up at freelance sites like Elance, Guru and oDesk.
The other 30% who are succeeding with outsourcing understand that software development, outsourced or in-house, is a process. It’s a process that’s meticulous in its preparation, management and execution. One process does not fit all, and finding the right process may be a journey . In an attempt to help reduce the cost of that journey, the remainder of this paper will highlight the process employed at SerpicoDEV. The intention of this paper is that you will gain the foundation of knowledge necessary to execute a successful outsourced software development project.
Very often, the first question asked by an inexperienced stake holder to an outsourced developer or company is, “How long will this project take and how much?” That is analogous to asking a contractor, “How much money and how long will it take for you to build me a house?” The first thing the contractor will say is, “I would need to see the blue prints”. The same is true for software development. Before an accurate estimate can be provided, a software development project must start with blue prints, or what are called “wireframes” in the software development world.
A wireframe is the blue-print of software development. However, there is a key difference. A house’s blue print may contain a door. A door is a known quantity. It opens, and shuts. A wireframe may contain a login button. But what exactly does the login button do? Does it open a new page? Does it open a lightbox? Does it do something else? Is it displayed if a user is already logged in? The cases for how to use a login button is called its “use case”.
Each control in a wireframe is accompanied by text explanation of its use case. Depending on the project, wireframes and use cases may take a few days to a few weeks to create. This is time that is well worth it. It creates a clear roadmap for all involved, from the stake holders to the PM’s to the developers, and creates a sense of accountability on all sides.
Once the wireframes and use cases are created, the next step is to create the estimates and the project plan. Can you see now how creating accurate estimates is facilitated greatly by detailed wireframes and use cases? The estimate phase will see a project manager and software architect reviewing the wireframe and use cases in detail and assigning estimated hours. The estimate is based on experience and research. For example, if a use case involves connecting Salesforce leads to a corporate report, the estimate may require time to research the appropriate API’s needed to implement the feature. The estimate phase should run anywhere from a few hours to a few days, again depending on the size of the project.
Once estimates are completed, a project plan is created. The project plan will address the number of resources to assign to the project as well as milestones. For example, if the estimate of the wireframes and use cases is 6 months, the project plan will decide if 1 developer will work for 6 months, or 2 developers for 3 months, or any other combination. The project plan will assign tasks with estimated hours and dates for completion. The project plan will be divided into milestones called “iterations” or “sprints” in the development world. The project plan should run about a day or two.
Was all this upfront work necessary? Or was it a waste of time and money? That depends… if you were building a house, would you want a blue-print and milestones of progress? Or would you consider that a waste of time, and just start digging a foundation and see where is goes from there? Software development is much less straight forward than building a house. Software development is complicated and requires a team of highly-skilled professionals that create and follow a plan. That’s why less than 30% of projects succeed. Once you created your wireframes, use cases, estimates and project plan, you are in the domain of the 30% of project that succeed. Now it’s time to code and implement the plan.
SerpicoDEV has implemented and followed a coding process that is highly agile, and involves customer feedback frequently. The process is one of plan, execute, test, evaluate... then repeat as often as needed to finish the sprint (recall that a project consists of a number of sprints). The planning phase of a sprint consists of creating QA test scripts for the testers to ensure the features have been coded properly and user acceptance scripts for the client to sign-off on the sprint. Both sets of scripts are vitally important and serve critical roles in the sprint. The planning phase also includes a knowledge share between the PM and the developers and testers to assure that everyone is clear on the goals of the sprint. The writing of the test scripts and acceptance scripts usually overlaps sprints. The sprint kick-off is about 30 minutes. The execution phase is hard-core coding. Developers doing what they do best: code your project. As the developers are coding, testers are swarming around them like bees on honey, ensuring that every feature is working as specified in the requirements. Progress is carefully monitored by daily 15-minute scrum meetings with the scrum master and the team. The goal of the daily meetings is to provide an open group forum for everyone to get on the same page by openly discussing what they accomplished yesterday, what they are working on today, and what they need to be successful. Throughout the day, the PM, developers and testers are in constant contact via email, Skype, GoTo Meeting and Spotlight PPM. This constant communication is key to an agile project’s success. It is one of the reasons SerpicoDEV chooses to hire exclusively in the western hemisphere where the time zones are similar. (There other reasons why SerpicoDEV hires in this half of the world… and it relates to talent and culture.)
Once all features in a sprint have been coded and tested, the progress is evaluated by the stake holders. The PM demos the finished sprint to the stake holders, who review the progress. The stake holders will then run their acceptance tests to verify that the sprint has been delivered according to specs. This is also the time when the stake holders may adjust course. For example, if during the project implementation, the stake holder decides a new feature is required for sales, or that the specs of an upcoming sprint needs to be modified, the review period of the sprints is the perfect time to make any course corrections.
Once the sprint has been accepted, and any changes to the original spec have been added to the plan, the PM measures the progress of the project and updates all involved with project burn down reports and up-to-the-hour progress updates via Spotlight PPM. The next spring begins, and the process continues until the successful delivery of the project.
You would never build a house without a blue print. Furthermore, you would never build a house without periodic inspections and approval of progress. Developing software is far more complex than building any house. The multitude of variables that exists necessitates an organized and agile approach to planning, executing and delivering. While there are many variations to the process described in this paper, the take-away is that a process is needed if your project is to be tallied in the 30%. Software development requires attention, care and diligence.
You will reap what you sow.
For a complimentary project evaluation, contact SerpicoDEV.