Project Initiation and MSF

Many organizations do not view project initiation activities as part of the project at all. In fact, the end result of project initiation usually marks the beginning of the project or no project at all if the project charter is rejected. With this in mind, it is entirely possible that you may not use Visual Studio Team System at all during project initiation. In fact, your team will probably start using Visual Studio Team System only when the project has been given the green light and the project team is ready to begin collaborating.

As we mentioned in Chapter 2, “Project Management Features of Visual Studio Team System,” one of the strengths of Visual Studio Team System is its ability to adapt to virtually any software development life cycle model. Out of the box, Microsoft provides you with the Microsoft Solutions Framework (MSF) as a basis of your software development projects that use Visual Studio Team System. In fact, Visual Studio Team System supports two flavors of MSF: MSF for Agile Software Development and MSF for CMMI Process Improvement, both stemming from the same sets of principles and process mindsets. We will refer to both as the Microsoft Solutions Framework or MSF (unless we need to differentiate one from the other).

Iterations in MSF

MSF specifies a highly iterative method of developing software that promotes a greater ability to adapt to change and refine processes and techniques to best suit the needs of the project. Iterations are fixed-length segments of time in which teams plan, schedule, and perform their work. All aspects of product development, from requirements definition through analysis, design, development, coding, and transition are grouped into these iterations, which typically last anywhere from 2 to 6 weeks. The duration of different iterations within the same project need not be the same length and can be adjusted to best fit the need of the process, team, and scope of the project. The project team simply continues through these mini-development projects until the completion of the project. As you might expect, different iterations can have a different focus as you progress through the development process. For example, the initial iterations of a project might be used simply to specify the requirements and solution architecture of the software you want to build; whereas iterations closer to the end of the project will likely focus more on transitioning the solution to a production environment or to the shelf for your customers to purchase. MSF refers to these themes as tracks and specifies five common tracks called Envisioning, Plan, Build, Stabilize, and Deploy. Furthermore, the MSF Agile flavor specifies a Continuous track, and MSF CMMI adds Governance and Operational Management tracks to this list. Tracks can be considered similar to phases in a project except that they can overlap; that is, it is possible for an iteration to be part of the Envisioning and Plan tracks at the same time. This means that activities performed during this block of time will involve both envisioning- and planning-related activities.

Feedback loops are essential to any adaptive system. In MSF Agile, iterations provide the opportunity for feedback to the team and the sponsors or customers who have ultimately requested the features in the software. At the end of an iteration, you should have a working and stable portion of the overall target system. By keeping the time duration of iterations brief (weeks rather than months), you are essentially tightening up the feedback loop thereby providing the opportunity for your team to adjust and adapt to any form of change.

The MSF Envisioning Track

The MSF Envisioning track is similar to PMOK’s Initiate process group in that this track’s focus is on the capture of the goals of the project and the constraints that help to specify the scope of your project. The primary output of the Envisioning track in MSF is the vision statement. Vision statements capture the context for the project and detail the events that have led up to the current business situation or need for the proposed product. The vision statement also specifies the major requirements and time frames that will drive the project and should clearly specify whether the project is driven by feature (software is not released until features are met) or by date (software will be released on a certain date regardless of the features completed by then). Figure 3-1 shows the workstreams in the envisioning track of MSF.

Figure 3-1: MSF Envisioning track workstreams

Note 

A workstream is used in MSF to represent a grouping of activities and roles on a project. For more information about MSF and workstreams, refer to Appendix B, “Microsoft Solutions Framework.”

MSF goes a bit further than what you might find in a traditional project initiation by adding tasks that create personas and set iteration lengths for the project. A persona is a more comprehensive way of describing a user of your software. Instead of the more conventional user type labels, such as administrator or corporate user, a persona works to capture the essence of your users by understanding aspects of their personalities such as related knowledge, skills, and general abilities. Personas take this even further by reflecting the essence of your users, detailing life history, personality quirks, interests, and hobbies. Adding deeper aspects of a user’s personality makes a persona more realistic. If you are familiar with the Unified Process or the Unified Modeling Language (UML), you might think that a persona is similar to a use case actor; however, personas are much more complete, allowing the traditional actor stick figure to come alive with a personality that your entire team can identify with. In many cases, to help reinforce this concept, teams give names to their personas such as Frank or Nancy rather than traditional stick figure names such as IT administrator.

When creating an initial iteration plan, you will likely use a calendar to determine how much time is available for the project and attempt to divide that time into smaller segments, taking into consideration the time needed to ramp up the team and put together the development and test environments, to construct the project, and to deploy the project. Remember, not all iterations need to be of the same duration. You might even choose to have a 1-week iteration in which the team performs technology assessments that will allow them to make good software design decisions in future iterations. For example, you might want to allocate an iteration for your team to evaluate new Microsoft ASP.NET 2.0 Web-based user controls or other recent technical innovations that would be beneficial to your team. Iterations dedicated to writing code usually last anywhere from 2 to 6 weeks depending on the size of your team and the complexity and relative size of the work your team is to undertake.

MSF Agile also specifies a Continuous track, which details a set of workstreams and activities that should happen continually throughout the project. Some of these workstreams can also be included with Envisioning activities in the initiating phase of a project, which involves refining personas, reviewing project objectives, and identifying risks. The Continuous track also specifies activities such as Evaluate Test Metric Thresholds and Triage Bugs; however, these activities truly can’t be performed until your team begins constructing the software. One of the more important initiating activities is the Identify Risk activity under the Guide Project workstream of MSF Agile. Sources of risks for a project can originate from usability requirements, reliability requirements, performance requirements, usage scenarios, complex business rules, integration interactions, or even ambiguous requirements. After you have identified risks, you can then do a preliminary impact analysis and prioritization of the risks. You may actually want to combine the vision statement, persona descriptions, initial iteration breakdown, and initial risk assessment into a project charter document to be submitted for project approval and ultimate activation. Risk identification should always have a high priority because these risks will help you to identify some of the finer details of your plan. For example, risk mitigation, the process of trying to prevent an identified risk from occurring, manifests itself as additional activities in your plan. Feature creep is a common risk identified by many project managers, whereby features are added to software during the software development process without any form of tracking or management. We all know that feature creep can harm our projects, but what can we do to prevent it? Possibilities include a formalized changetracking process and a functional baselining and sign-off system. Each of these mitigations will result in extra work that will need to be performed by your team and integrated into the overall project plan.

As you can see, tasks associated with the MSF Envisioning track have little to do with Visual Studio Team System. When you do get approval, it will be time to dive into Visual Studio Team System, and when you do, you will start by creating a new Team Project. At this point in the book, however, it makes little sense to fully explain what you and your team will be doing during the MSF Envisioning track without taking a closer look at Visual Studio Team System, and specifically, Team Projects. Once you get a better understanding of the structure of a Team Project, it will be much easier to understand how Envisioning tasks fit into the bigger picture and better prepare you for planning activities. With that said, let’s take a break from project initiation activities and pay a little more attention to Visual Studio Team System.