Project Planning

In Chapter 3, “Project Initiation,” we discussed the work required to start a new project or begin the new phase of a much larger project. In this chapter, we take a closer look at project planning activities and specifically how they relate to Visual Studio Team System. As we did in Chapter 3, let’s start by gathering some insight from the Project Management Body of Knowledge, or PMBOK ( http://www.pmi.org/info/default.asp).

Every project requires some degree of planning. Generally speaking, the more risk and complexity that is involved with a project, the more planning you will perform. PMBOK has broken down project planning into 21 different planning activities, the purpose of each to help to further identify and specify aspects of the project that could not be fully explored during project initiation. Should you plan every project in the exact same way? That’s probably a decision you will need to make with your team and your project sponsor, because every project is different with regard to size, scope, complexity, and risk. Planning activities are designed to specify a more concrete view of project scope, cost, schedule, and team activities by working to uncover, explore, and possibly resolve aspects of your project such as activity dependencies, requirements, risks, constraints, and assumptions.

Planning activities should be performed iteratively, because this method ensures an important feedback mechanism that help to guarantee that you are on the right track. It will help you will ensure that you can adapt to realizations that you and your team make as you refine your understanding of what you are delivering and how you should deliver it. You and your team can also gradually adjust your understanding of the customer’s needs and help drive decisions regarding the depth and breadth of future planning activities. This approach can be risky because it is possible to plan without actually producing real value. The amount of project planning you engage in should be driven by the value that your team, including your customers, receive as a result of these planning activities.

Important 

Do not restrict planning activities to a single planning phase. Planning activities can and should happen throughout a project and can overlap project execution activities in which you will be actually building software.

Note 

You can obtain more information about the Project Management Body of Knowledge from http://www.pmi.org/info/default.asp.

Let’s take a look at the planning activities specified by PMBOK so that we can later map these activities to Visual Studio Team System and the Microsoft Solutions Framework. Start by performing an activity PMBOK refers to as a Develop Project Management Plan, which is responsible for outlining the level of planning you will perform for your project and how the resulting plans will be used to drive the remainder of the project. The result of this particular planning activity is a project management plan, in whatever manifestation it takes, such as a document or a list of tasks on a whiteboard, the details of which will vary by project condition and complexity. You will continue to update this plan as needed throughout the life of your project and upon agreed to by you and your project sponsor. These project management plans detail additional information such as descriptions of tools and techniques used to make certain plans, the monitoring and control of changes, and the way that management reviews should be performed to address open issues and pending decisions.

The next cluster of activities specified in PMBOK’s planning process group revolves around scope, specifically scope planning and definition. Project scope attempts to specify exactly what you are building and what you are not building. Think of project scope as the view of the finish line in a marathon-you know you must cross it to complete the race. We use the term initial view because changes to project scope are almost guaranteed to occur throughout the project, especially after users begin using your software. As with planning in general, the level of scope planning will be different from project to project. For example, an internal research project consisting of a small team working on a fixed-cost and fixed-duration project may have fewer scope considerations than a project delivering financial management software to millions of online subscribers. Scope planning typically results in a scope management plan that determines how your team will go about setting scope and developing an initial scope statement, and it establishes the change control process that the team uses to control scope. The scope definition activity specifies project scope, which is based on acceptance criteria, constraints, risks, budget, approval requirements, and milestones known at the time. To set the scope, identify a set of requirements (usually in the form of features).

Note 

Traditional models of planning suggest that these activities produce a great deal of documentation. Planning is an activity, not a document. Planning must be performed; however, it doesn’t have to be a daunting or an extremely boring task. Planning can even be performed in a workshop setting using whiteboards and sticky notes. Every project will have some degree of planning, and it will be up to you and your team to decide how much planning is enough for the conditions of your project. The key outcome of the planning activities discussed in this chapter is to figure out who does what and by when. If you are using Visual Studio Team System, the results of planning will likely be manifested as work items assigned to iterations.

Importance of Good Requirements

This may seem very obvious, but good requirements will be one of the most important factors for a successful project. In his book Software Requirements (Microsoft Press, 2003), Karl Wiegers points out a number of benefits to having good requirements, including fewer requirement defects (a requirement defect is the building of the wrong solution), less frequent reworking, fewer unnecessary features (keeping the scope as small as possible), lowered enhancement costs, faster development, fewer miscommunications, reduced scope creep, less project chaos, better testing, and higher customer satisfaction. These are clear benefits, and they can be achieved only through good requirements.

What makes a good requirement? Again, Wiegers provides some insight by listing what makes good requirements such as being complete, correct, feasible, necessary, prioritized, unambiguous, and most importantly, verifiable. Verification is extremely important because it ensures that a test can be created for the requirement, and the system can either pass or fail the test. For example, the requirement “The system must respond to every user request within two seconds” is an example of a verifiable requirement, as opposed to “The system must perform adequately,” for which no test could ever be written.

The creation of a work breakdown structure (WBS) is also another activity specified by PMBOK as a planning activity. Work breakdown structures represent a decomposition of your project’s main deliverables and tasks into smaller, more specific pieces. The work breakdown structure represents the entire scope of the project in hierarchical tree format, the leaves of which represent the actual work. Leaf-level detail in a WBS is typically detailed enough to be estimated, scheduled, monitored, and controlled. There are a few different ways that you can organize a work breakdown structure. The first is by phase, in which the primary branches identify the phases of your project, such as assessment, construction, and transition to production. Another way you can organize a work breakdown structure is by functional area of your application, whereby branches represent features of your application, and the highest level of detail represents tasks required to construct each feature or feature area. One of the most common ways to construct a work breakdown structure is by relating it to the underlying process framework by depicting workflows, phases, and deliverables. Here the main branches of the work breakdown structure would depict the type of work, such as management or implementation, further broken down into phases of the project, and then finally by deliverables for each phase, as shown in Figure 4-1.

Figure 4-1: A work breakdown structure based on the Unified Process that specifies workflows, phases, and deliverables

Risk planning is yet another type of planning, specified by PMBOK, which is broken down into a number of discrete activities such as risk management planning, risk identification, qualitative and quantitative risk analysis, and risk response planning. Essentially, the goals of these activities are to try to predict what might go wrong with your project, to decide how to prevent these risks from becoming reality, and to create a strategy for dealing with them if they do become reality. You develop your approach to risk management during the risk management planning activity. Risk identification activities help you predict problems that could affect your project, and qualitative risk analysis prioritizes these risks by estimating the probability of the risk happening and the impact it will have on your project. Quantitative risk analysis is a process that tries to analyze, numerically, how risks will impact the overall objectives of your project, Conduct risk planning continually throughout your project, and integrate risk mitigation tasks continually into your team’s activities.

Activity planning is another type of planning specified by PMBOK. Activity planning divides into more specific tasks work in the work breakdown structure; the lowest level of these is called work packages. The activity definition task decomposes work packages into tasks called schedule activities. You can then sequence these activities through the activity sequencing activity by performing the activity resource estimating and activity duration estimating activities. You can compile the activities into an overall project schedule through the PMBOK activity called schedule development. It is important to note that activities that represent risk mitigations should also be fed into the schedule even though these activities do not specifically focus on producing work specified by a work package.

PMBOK specifies quality planning as another activity that is performed in the planning process group. Quality planning helps to identify the quality attributes your team will try to achieve and the steps you will take to try to achieve them. Quality planning is not a one-time activity and should be addressed throughout the product life cycle. It is important to note that the way you address quality in your life cycle will probably impact the schedule and the cost factors of your project.

The most important aspect of your project is probably your project team because the development of software has more to do with how your team works together than the technology you are using. Because of this, give consideration to human resource planning, which logically extends into contracting, purchasing, and communication planning, which are all also specified by PMBOK. Human resource planning specifies the roles and responsibilities on your project, ensuring that all team members understand their commitment to the project and their fellow team members. This activity is related to communication planning, which helps to determine the information that is communicated to your team and the project stakeholders. Contracting and purchasing planning focus on the approaches you will take to obtain resources, in the form of people, knowledge, technology, or tools, that you currently do not have on your project. Obtaining resources must be addressed as an integral part of project delivery.

The activities and the schedule you derive from work packages coupled with risk mitigation activities will form the basis of cost estimating and budgeting activities specified by PMBOK. Unless you are developing software for the open source community, virtually every project will have a cost associated with it. The cost estimating activity specifies the process needed to develop an approximation of the costs in terms of people and other resources required to develop your software. Cost budgeting creates a baseline of costs from the compiled estimates of activities and work packages. Beyond a doubt, PMBOK acknowledges that cost estimating and budgeting are not static activities and will likely be refined as your team progresses through your process life cycle.

As you can see, PMBOK paints a very comprehensive picture of all the activities normally associated with planning. It cannot be overstressed, however, that PMBOK does not suggest that these planning activities happen in a single phase in your project; many of these planning activities will continue until project completion. In addition, PMBOK functions as a reference manual and does not dictate the level of planning you must perform on each and every project. The specific activities and the depth you must go into in each of these will vary from project to project and from team to team.

Note 

A common misconception is that projects based on Agile methodologies do not place as much emphasis on planning as projects based on a more traditional waterfall model project. In fact, with Agile-based projects, you will likely spend a great deal more time planning your project throughout the life of your project because planning and adapting to change is a continual aspect of an Agile project right up until delivery. So no matter what kind of project you will be managing or what methodology mindset you will be using, you will be doing some form of planning.