One of the hardest parts of a project for me is at the very beginning, getting started. The start of a project represents an awkward and yet immediate transition from what do I know about the project and, what do I need to know. What you do know is generally what your client, customer, or manager just told you about the project: “I need a humdinger that will zoom, zip, and fly.” This, however, is where the awkwardness comes in, you now know what they think they want, the difficulty comes in translating that into a final product down the line. And so naturally as a software engineer you start to ask questions about the product. This is the start of finding out what you need to know, what the client means by “humdinger” and how exactly “zooming” and “zipping” relate to it.
This transition is a hard one because you begin with, most likely, a very vague understanding of what the client wants and its your responsibility to take that understanding and materialize it while they watch. But all you have is a vague statement, so what does the final product actually look like? what does it really do? who are all of the stakeholders? This all translates into a simple question of the scope of the project, and more importantly of version 1.0. Tied neatly into this question of scope is the whole bundle of what you and your teammates are as software engineers going to be doing until that 1.0 arrives and the client signs off on it.
Scope, to me, is a scary thing, it defines not only the final product but more than likely it heavily impacts the core of your technology. If you decide that these certain features are not going to arrive until 2.0 then you have to make sure that 1.0 is going to fulfill the architectural qualifications of allowing those features to be built in later. Scope represents what you need to consider along the way of getting to 2.0 while you’re really just working towards 1.0. This is where risk comes in, in my opinion to save the day.
So, as I sit there with my teammates questioning what it is exactly the client wants and what I need to know in order to deliver it, risk starts popping up. What if I don’t understand the client, the product, my responsibility, and so on. Then reason and “project” kicks in and you start to look at your life cycle options. Risk based life cycle models like the spiral or more refined win win spiral are excellent at starting projects appropriately. More than likely all projects will start with some sort of problem of scope, meaning “what exactly was the client talking about?”. With other life cycle models you may start with feasibility (waterfall), or some other standard starting point, or some other general direction. But with risk based life cycle models you are immediately addressing the concerns that you face with the product. If you understand the product but have another risk, then you can gladly and rightly start with this.
This is where solace enters into the start of a project, because with other models you may have a place to start, or not, with risk based models you can immediately start to deal with the things that make starting a project so difficult. If the team says “what exactly is a humdinger?” and that’s the largest risk, that’s where you start. If the team says “I understand the product, but the timeline is too short” then you can start with reasoning out version 1.0. Of course working with other models will certainly work, I would say that time has proven that using any number of models, including risk based, will work. But one of the nicer aspects of risk based models is that instead of concerns on the backburner until the model allows time for it, with risk based models it can be immediately addressed. This allows for a nice amount of stress to be dropped at the beginning of a project.
– Legit
Michael Lopp is a middle manager of software engineering teams, having worked at various companies in the Silicon Valley including startups from the age of the internet boom his experience is truly varied.