The problem with milestones is once a date is set for the milestone, activities beyond the milestone need to wait for the milestone to be achieved. This poses considerable waste, especially when the milestones are defined a priori before the project starts. Every project is different and need an adjustment to the lifecycle objective milestone definitions. This is best done dynamically and I will describe how this is achieved using state-cards.
I normally do this during my first contact with project teams as a way to understand their state of development. I evaluate the development state by considering 4 different aspects or dimensions of development, namely: Vision, System, Project and Team.
- Vision. This is the business and value aspect. The vision communicates the value, the rationale and the benefits derived by developing the product (system-software). All systems are developed to achieve some vision. It answers the questions “why” and “where.”
- System. This is the technical aspect. The system embodies the things to be delivered to fulfil the vision. They including software, hardware, documentation, etc. It answers the questions “what” and “how much.”
- Project. This is the work management aspect. It embodies the work to be conducted to build and deliver the system. This includes milestones, schedules, and so on. It answers the questions “when” and “how soon.”
- Team. This is the teamwork aspect. It is about how well the team is working together and how they collaborate with others outside the team. It answers the questions “who” and “how well.”
The state for each aspect is summarized in Table 1. For brevity in this paper, I will not go into the criteria for each state. Anyway, the criteria only serve as a guide. Most teams would adjust them anyway, but I have found that the states themselves are fairly generic. I made a deliberate attempt towards a very small number of dimensions for simplicity as I believe most teams can fill the missing bits themselves. I want to start light - as light weight as possible. Incidentally, there is ongoing work in the SEMAT initiative  to define these dimensions universally.
Table 1: Application Lifecycle Dimensions and States
As I explain here, for each state, I ask the team members in which state is their development.. If a particular state is completed, I will move the card to the left. For those states that have yet to be achieved, I will shift them to the right. So, completed states are on the left and pending states on the right.
Figure 4: Determining Development State
Then, I do something very important. I take the first pending state and put them in the middle and I push away the completed states and the other pending states. The result is shown below in Figure 5. I call this “Parting the Red Sea.”
Figure 5: Determining the Next Development Target – Parting the Red Sea
Even though each card is concise, it is important to reduce the number of cards in play. So, I take the 4 cards in the middle column and lay them out in front of the team and tell the team these cards represent their immediate goal in order to meet these targets. This is their next immediate milestone.
Figure 6: Formulating the Next Milestone Definition
Of course, it would be useful, even comfortable, to have some canned definitions of milestones. The Essential Unified Process has such a mapping of states to the Unified Process milestones, i.e. Inception, Elaboration, Construction and Transition. You can do likewise with the cards I have.
However, I prefer a more dynamic approach as I have previously described. Having the team coming up with their milestone definition is powerful. You give them a sense of ownership and empowerment. This is a departure from a process engineer telling them to meet a set of objectives without their buy-in. The best process for the team is what the team defines, not what others define. However, teams usually do not have the background or experience to do so. The state-cards bridge this gap by providing the basic building blocks.
4. Lean Iterative Management with State-Cards
I always tell my clients that development produces two things, features and decisions, based on compromise and negotiations. Ultimately, features are what customers and end-users want. But not all features are the same. Some are very difficult and challenging and need some kind of investigation and consensus before actual development can take place. For these features, some important decisions need to be made. These decisions are usually architectural in nature – they affect the technical architecture and might even affect the business architecture. I have in my deck state-cards for both features and decisions (see Table 2).
Table 2: Feature and Decision States