Spiral Development, the 80/20 Rule and SharePoint
In the late 80s, Barry Boehm, then a chief scientist at TRW, devised "spiral development" as a way to reduce risk on software projects. Long before that, Joseph M. Juran put forth the Pareto principle, also known as the 80-20 rule. These many years later, I find that the concepts of spiral development and the 80/20 rule are still unknown to many, and they have much to offer. You can certainly Google these concepts to get lots of perspective and gory detail. I ran across a 50-page report by Boehm, which has more detail than you probably need. Let me try to boil it down and relate the principles to SharePoint's value proposition.
Until next week, all the best!
Dan Holme
The 80-20 Rule suggests that there is a "law of nature" that 80 percent of your return comes from 20 percent of your investment. It is obviously not a scientifically supported rule in every situation, but it does apply in a surprising number of scenarios. I like to relate the 80-20 Rule to the concept of "low hanging fruit." There are always opportunities that you can capitalize on, easily, and then there are opportunities that require significant more investment or risk to actualize.
Spiral development centers upon concepts of incremental development and customer feedback. The idea is that when you start a project, it's the exception rather than the rule that you can enumerate all of the requirements perfectly. Most projects are meant to deliver a product or service to a customer. Often, the customer's needs are not fully known or communicated, and it is through experience and time that the requirements bubble to the top and are completely understood. Therefore, it is folly to invest in a single overblown design phase, because when the product or service is delivered, the customer will react. The customer will say, "Oh, that's not exactly what I meant..." or "This doesn't work the way I need it to." or "Wow, it would be fantastic if it could do this..." So, instead, you build a prototype based on the requirements you know, you deliver the prototype, and you achieve two things: You start solving the customer's problems, and you gain feedback that you then take back into a revision.
Putting these two principles together, you start to get some great effects. Let's frame this in an IT scenario. There are probably problems that affect 80% of your users, and which can be solved with reasonable effort to address 80% of those affected users. Or, there is something you can deliver with reasonable effort to boost user productivity by 80% in a certain task. If you were to try to meet 100% of the needs, you would have to invest 4x the effort, and that last 20% of "need" (or "pain" or "requirements") are not only 4x harder to address, they're most likely the requirements that are not fully understood, so you're likely to think you reached the 100% mark only to find out that the requirements weren't fully enumerated. In other words, your "finish line" moved!
If this sounds complicated, it's not. It's all about recognizing, going in to a project, that you likely do not know exactly what the outcome should be, but that you know the direction you're heading and you can find the first big mileposts - the requirements that will solve 80% of the problem. You then trust that the process will get you all the way. And you recognize that the passage of time, and customer experience with what you are delivering, is required for you to get from 80 to 100. It's virtually impossible to chart that part of the course up front, and if you try you will likely invest far more effort in an over-engineered deliverable that, in the end, doesn't quite hit the mark.
Anyone who has worked with me as a consultant knows that I follow the 80-20 Rule and Spiral Development tenets. When I dive into a project, I set milestones that allow deliverables to be produced that start to address the known problems, which are often those 80% of the problems/requirements that take only 20% of the effort to solve. The remaining 20% of the problems/requirements are addressed in spiral development, based on prototypes and customer feedback at each stage. And guess what - by integrating the 80-20 Rule and Spiral Development, that last "20%" of problems actually takes less than the 80% of the effort it would have, if we'd tried to tackle all 100% of the problem without spiral development.
Why do I talk about this in relation to SharePoint? It's because, as regular readers know, I think the fastest road to successful implementations and user adoptions of SharePoint is to follow this model. The exact path the model takes you down will vary based on your enterprise, your problems, your requirements, and your constraints, but the model will work.
This summer, you know that I followed the 80-20 rule to deliver solutions to support the broadcast of the Olympics. I'm currently working with several clients on solutions based on this model. One client has a very stringent "project management" model, which all but mandates full understanding of requirements, solutions, and costs before development can even begin. That type of approach can get in the way of actually delivering a solution, because you often end up in a chicken-and-egg dilemma in which you can't begin to understand requirements (and therefore solutions and costs) until you begin to deliver part of a solution (spiral development). We managed to work around that project management requirement for a current initiative, and we've developed a solution that, I believe, will address 80% of the team's needs. We've done so with out-of-box SharePoint capabilities, and we've done it in about a month. The team can now proceed to meet its objectives, and everyone is very happy. It could never have worked under the "project management" requirement because the team needed little hands-on experience with rapid-developed prototypes (spiral development) to understand that their objectives (which obviously they know better than I) could be met much more easily (20% of the effort) than their original technical requirements had suggested.
What's the moral to this story? Whether it's SharePoint, other technology, business, or personal projects, don't get caught up in overly rigid development models. Listen to your customers. Do what you can to deliver solutions. It's more important than ever in today's economic climate, right? Listen to your customers and triage their requests so that you can meet 80% of the need with 20% of the effort. Then you can decide whether it's worth the 4x effort to get to "100%", or whether there are other low hanging fruit to harvest. Life's short, time changes everything, and what looks like the finish line today won't be the finish line when you get there. The only way to stay sane and productive is to have a model that recognizes that reality.
danh at intelliem dot (top level commercial domain)