Visit Project OSLís wiki here for an introduction to Project OSL.

Project OSL is my senior project. I am lucky enough to be working for a team that I feel very comfortable with and agree with on some fundamentals. However, these fundamentals are good to analyze for our own purposes and for purposes of giving back to the community. In addition, our project may become the model for Agile software development in senior projects. One of the things that we all just naturally agreed upon is that we should use risk to identify feature priority. While not radical to us, this may seem odd to some.

Feature prioritization is a huge part of project management and software development. It is important to analyze what features you should be working on and why. For our team, we have decided to work in short, manageable cycles that go through the entire cycle of software development from defining use cases, feature prioritization, development, testing and publishing. The project cycle should be covered in another post.

So, how do we do feature prioritization? Most teams will start with a basic set of features where they can create a system architecture that they can build modules from. This seems to make sense; the architecture is in place and features can be easily added as ìmodules.î However, this leads to several difficulties and problems. The architecture must be created and defined at the beginning of the project when the developers know the least about the technology, the application domain, limitations, user needs, etc. The goal of the architecture is to create one that could support all of those variables. That is a very difficult task to capture which requires the foresight and knowledge that I nor the rest of my team possess. Instead, the software architecture should be defined as late as responsibly possible.

Instead of focusing on software architecture, our team has decided to focus on features and delivery while reducing risk of project failure. We focus on features because those are the core components of our systemófeatures are what consumers care about. We also focus on delivery. Release early, release often is a philosophy championed by web application giants like Google and 37 Signals. 37 Signals even published a book that covers this philosophy. If you have an interest in web development, you must read Getting Real by 37 Signals. Its free to read online (though I prefer physical copies myself). So, the focus on features and delivery has a compelling case; it even has two industry leaders heralding the philosophy. But, why do we focus on risk?

Reducing risk of failure is a key component of project management. In fact, if project management did not reduce risk of failure for engineering projects, it could be argued that management had no role in engineering. However, it does. Project management attempts to control risk of failure by setting up safeguards such as process, metrics and risk analysis. These are all aimed at two things: reducing risk and increasing productivity. So, our team believes that it is key to identify risks and attack risk as early as possible, reducing the likelihood of failure.

Imagine a situation where there is a component in the system that is 100% likely to fail. In the standard feature development schedule, this feature may be in the 50%-60% range of features that need to be developed. So, the team chugs along until half way through the project they find that a core component to their system is going to fail. Now, they have to do some serious damage control. They could change the architecture; they could change the project scope; they could scrap the project; they could ignore it and hope it goes away. None of these are desirable and none are especially desirable after a company has invested half of a projectís budget.

Instead, imagine if the feature were developed first. It was identified within the first few weeks of development. The developers go to the project manager and the PM makes a decision. Here, his decision is easier, cheaper and less frustrating to the team. The risk is dealt with and the total risk of the project immediately drops. The project is far more likely to succeed.

Obviously, this is an extreme case and it is very rare that a feature is completely doomed to failure. However, if we apply the same principle to high impact, high risk features we should be able to reduce much of the technical risk involved in creating a system.

So, that is how our team operates. We are currently in Release Cycle 1 developing the Top 10% high impact, high risk features of our system. After we finish this cycle, we can re-evaluate the project and take on the next 10% high risk, high impact features. The best part of developing this way is that, as a team, we can feel very, very confident about the success of our project after the first cycle. That is a rare commodity and, with that confidence, I believe we can go on to create a superb product for OmniGroup.