On the surface, software development sounds simple enough: write some and code and ship the product. If you are a hobbyist, that model works. In the realm of insurance software, however, things get a little more complex. As the Director of Software Development here in the Portland, Maine office of AMS Services, I am one of the people responsible for assigning and managing development staff for various projects. So what types of issues do I face? Let’s start with product releases. While the specifics may vary, there are always certain project “goals” that remain the same:
1. Deliver well-considered, fully-functional features that delight our customers.
2. Deliver against the shortest possible schedule.
3. Keep defects to an absolute minimum, with no critical defects by ship date.
4. Deliver software that will be maintainable into the foreseeable future.
5. Stay flexible during “project x” in case we need to move people around to meet other needs or shift feature priorities mid-stream.
And it doesn’t end there! It also goes without saying that I need to ensure that my staff is both happy and productive. This means that I must make sure that they are staying current with development platforms/languages, development practices, tools and techniques. We also have to balance maintaining existing product and responding to customer-reported issues while we work on new product releases with new features – operating within budget, of course. (This would be so much easier with an unlimited budget.)
Even before a project starts, my work begins. When a particular project is conceived, I have some fundamental questions that need to be answered.
What needs to be built?
At a minimum, I need to understand the project objectives and scope at a high level. The primary concern here is that anyone I allocate to a project must understand what is being asked of them, because if they don’t we’re assuredly getting out of the gate on the wrong foot. This will lead to wasted time with the project team as a whole along with complicating my life in terms of assessing individual performance.
What type of effort will be required?
Answering this question involves understanding the first question, but it also means that I need some idea of the overall development effort required. For a project staffing exercise, this is usaually a ballpark “guesstimate” to provide me with some idea of what a given project will take from a development standpoint. We look at the business need, assess the technical need, and put the effort into a small, medium, or large bucket. This information is useful when considering the next question…
What is the expected time frame for delivery?
This is a fun question! The shorter the time frame a project has, the greater need for concurrency and hence, greater staffing. Of course, there are always dependencies and an order that development work must occur, which means that everything cannot be worked on in parallel. Gaining an understanding of this – again, using high-level, usually incomplete information – will place some natural constraints on the number of developers who can work productively on a given project.
Answering this question also helps determine if we need to discuss/negotiate expectations. Everyone likes their projects completed yesterday, but more often than not software projects – even simple sounding ones – are more involved than most people expect. As we work through answering this question, the various stakeholders begin to get a feel for just what is being bitten off in terms of time, effort, and ultimately dollars.
There will be decisions as a result of getting this far. After all, timing and budgetary constraints may be blown out of the water, leading the stakeholders to defer on proceeding with the project altogether. Another possible outcome is that a given project – as defined – will cost more than the project stakeholders would like to spend, but… there are some nice-to-have features that can be stripped from the project to provide an acceptable return on investment from the value received from the higher-priority features. At other times the decision will be to accept the time cost because the project is deemed SO important that it must be done.
What skills and knowledge will be required to complete the project?
Some projects are also more inherently complex or demanding in terms of the skills and knowledge required than others. In order for a project to be successful, I need to align the needs of the project with the correct development talent. As a rule, I strive to leverage people’s strengths as much as possible, and I also look to align people with projects and people so that their individual career goals and objectives are met. (And yes, there are times when I have to make some hard choices and err on the side of project success over giving someone a chance to try something new.)
Who will participate with the customer team?
Since we have adopted the Agile development methodology, we use what are referred to as “customer teams” – individuals who are or represent the end user of the software. Ideally, customer teams should be staffed with business people who understand the business and understand what they want to get out of the software. Why?
Developers need guidance and information to write software that meets the business need, and I like to make sure that we will have someone available to answer those inevitable questions about how the software is supposed to operate. Without this input, I know that we will either fall into the trap of guessing (and likely be wrong) or risk being stalled because we aren’t getting timely input.
Pulling it all Together
The combination of understanding the high-level project goals, expected time frames, staffing and skill sets required, and ensuring we have the right resources lined up to answer questions help me to forecast – even before a project starts – where we might run into trouble. I can take steps to mitigate problems where a lack of training or knowledge might be a problem.
As always, I need to remain ready to shift resources if some pressing problem arises (something I do only if absolutely necessary, and as rarely as possible). While we strive to remain organized and staffed for contingencies, we aren’t making widgets! Each week presents new challenges and wrinkles, and in my mind the “plan-do-adapt” model espoused by Agile development certainly captures a managers-eye-view of the software development world.
So far, all we have done is warm up; I’ve given you a managers perspective that comes into play before a project even starts. In upcoming blogs, I’ll delve into various topics related to development, starting with defining and understanding the requirements.