No Wasted Effort

In software/application/system development projects I get the sense (from experience) that some of the deliverables required in a project are not considered to be value-adding products. The short answer to this issue is, Cut Them. If something doesn't add value, don't waste effort, time or money doing it.

The problem that I have seen is that there is a prescribed methodology that a development team must use regardless of the scope of the project. The team automoatically programs these deliverables or products into the project without regard to what is needed. The funny thing is that this situation is the result of a pundulum that has gone too far. Ten years ago the oposite was the case. People would initiate a project without identifying any deliverables except the final software/application/system.

This area of discussion is concerned with one thing, what is the required visibility the owner of a project needs to feel comfortable with the progress of development? Ten years ago the required visibility was zero. We saw what happened. Developers built what they thought the customer wanted, and there was a separation between the user and the developer. The result was that products didn't meet the needs of the business. Additionally the cost of adjusting the product so that it met the needs was seen as too high.

In reaction to that a host of methodologies was developed to afford visibility into the process. From this sprang the Waterfall methodology which was very benchmark and gate oriented. This helped to get alignment with business requirements, but the cost was in terms of schedule and price. Waterfall project would deliver on scope but the business would have more evolved needs which typically invalidate part of the software/application/system. What I mean is that by the time the product was delivered the business need had changed.

In response to this, the Agile Rational Unified Process (RUP) was developed to get products to market faster and in greater alignment with current business requirements. I believe in and subscribe to this process. But what does it actually mean? That depends on who you ask. I will tell you what it means to me. Perhaps some inspired people will take the time to help me to think in new directions; I welcome that.

To me the Agile RUP means that there is no wasted effort and that we are building and expanding our knowledge of a particular element of the product as every step of the process. I begin the process with a statement of the Business Need. Essentially what is the problem that needs fixing. This is what typically goes into the business case which is reviewed for project budgeting. That is a post for another day.

But from the Business Need we should be able to identify the Objectives of our project. These Objectives are going to be very important later when we get to User Acceptance Testing. The Objectives must be SMART Objectives, they must be agreed upon by the owner(s) of the project or the steering (core) project team. Objectives are NOT requirements. Do not waste your time attempting to specify requirements in place of Objectives. I would suggest no more than seven.

With the Objectives in hand we will begin the process of looking at and analyzing the baseline business process. There is always a baseline business process, even on a new development project. How would we perform this activity today? Work with the right users to talk through the typical scenarios for how it works today. Identify the actors and actions. Develop Activity Diagrams, Use Case Models and Use Case Narratives.

Next, with the Baseline products in hand, focus now on what the Business Process should look like. Get people to take that King for a day atitude. What would you change... Develop Activity Diagrams, Use Case Models and Use Case Narratives.

You are now done with the first segment of your project and ready to produce the first really meaninful artifact of the project, a Concept of Operations (ConOps). Your ConOps should be based on the IEEE 1362 standard (it is a little bit nuts that I know that off the top of my head). Clause 3 identifies the baseline business process. Clause 4 identifies the things you want to change in the business process. Clause 5 identifies what the end product should look like. Do NOT let technical people write your ConOps for you. It will lose its value if you do. The ConOps is a business-specific document that should be digestable by business stakeholders. It should be in the neighborhood of 15 pages max. If you can't get it down to that size, you should think about chunking your project (another post for another day). Business people should be able to read the ConOps and say, "Yep, you got it." If they don't say that, do not leave this phase and go on to the next phase. Stay here until you get that kind of response from the business. If you don't follow this rule, you will be developing the wrong thing and ut will cost more and be more painful than it would have been otherwise.

ConOps in hand, we are going to progress and elaborate the Benchmark Activity Diagrams, Use Case Models and Use Case Narratives. How many are needed? As many as it takes to identify all normal flows through the software/application/system and enough alternate flows to provide the right visibility to the business. It could be two, or it could be two hundred. This is a balancing act that the Project Manager must feel his or her way through. These detailed artifacts are going to be really important as we use them to establish traceability through the next set of artifacts.

It is at this point that you are going to program use cases for iterations. I believe in the just in time process for this segment. If Use Case 10 isn't going to be built until Iteration 4, don't even look at it yet. Focus on the use cases involved in the current iteration. Get that segment of functionality perfected. For example if Iteration 1 is focused on Use Cases 1, 2 and 3, you are going to want to mature all of the details related to those Use Cases, as well as their requirements and design.

The Requirements Specification should be divided between the functional requirements and the non-functional requirements. Each functional requirement must be tied to an Activity Diagram, Use Case Model AND Use Case Scenario. This will be important later, trust me. I have the business stakeholders review and comment on the functional requirements and the IT stakeholders comment on the nonfunctional ones. But it is important that the business signs off on elements of the nonfunctionals as well. Uptime, data quality and the like will impact the business. They will need your help in translating these from Geek to American.

Separately I always program a special requirements document called the Data Requirements Document (DRD). The Data Dictionary, data types and ER Diagram should be reviewed by the IT stakeholders. The question to be answered in this review is, does this product allow for the type of growth this product would need if it was completely successful?

It is important to realize that you will be reviewing Requirements n number of times (where n = the number of Iterations). It sounds like more work, but it is actually less work, and I'll tell you why. Have you ever tried to review a 150 page Requirements Specification? How about a 15 page one? I would probably soak 40-60 hours into the former, and an hour or two (max) into the latter. Trying to find a 40-60 hour block is impossible, so it takes more than a month to get the big document reviewed. Whereas the mini spec, with the requirements related to Iteration 1 is out the door in a week.

With the requirements now specified, focus can shift to design. There are 2 segments to design: technical design and functional design. Don't waste the busines's time by having them review artifacts that they cannot help. They will not be able to add value to the technical design. Don't bother them with that. The Geek Squad will not be able to add value to the functional design, don't bother them with that. You should receive a segment of design that corresponds to the content in the Iteration.

Once the Iteration is delivered add a column to the Requirements Spec, Design Doc. and Use Case scenario. This is your test (verification) column. Walk through the Use Case and identify all deviations or areas where the product didn't function as anticipated. When issues are identified, try to put a note in for specific requirements that are affected as well as design sections.

Timely comments in Iteration 1 should be addressed in Iteration 2. Iteration 2 is not a separate set of functionality, it is everything Iteration 1 had plus some additional Use Cases, Activity Diagrams, Requirements and Design. You review the documents for two things; first, all comments from It 1 are addressed and It 2 functionality. Add your columns for testing and continue until you have developed all the functionalit.

Do you remember when we created those Objectives at the beginning of the project? Hand them out again. Those objectives are the test plan for your User Acceptance Test (UAT).

That is how I see it. That is the right amount of visibility I like to see ti keep things on track. What do you think?