Project Planning for Task Coach

As announced in a previous posting, I am investigating which of the CMMI goals are achieved by the Task Coach project. The third process area I am looking at is Project Planning (PP). PP is a Project Management process area at level two of the CMMI for Development. Because PP is part of the core model foundation, it is also part of the other two CMMI constellations, CMMI for Services and CMMI for Acquisition. But here, I'll be looking at PP from a development perspective.

According to the CMMI, "The purpose of Project Planning (PP) is to establish and maintain plans that define project activities." Unfortunately, CMMI doesn't define the word plan. However, CMMI defines project plan as "A plan that provides the basis for performing and controlling the project’s activities, which addresses the commitments to the project’s customer." We'll assume that the plans mentioned in the purpose statement of PP are meant to be project plans.

PP has three specific goals and, like all CMMI process areas, five generic goals. For now, I'll only be looking at specific goals.

The first specific goal (SG1) of PP reads "Estimates of project planning parameters are established and maintained." In the explanation of this goal, CMMI states that "Project planning parameters include all information needed by the project to perform the necessary planning, organizing, staffing, directing, coordinating, reporting, and budgeting." For a small open source project like Task Coach, the amount of necessary planning, organizing, staffing, etc., is probably much lower than is needed for commercial software development projects. To achieve this first PP goal, CMMI expects organisations to implement four specific practices. Let's see how these apply to the Task Coach project.

The first specific practice (SP1.1) of PP says "Establish a top-level work breakdown structure (WBS) to estimate the scope of the project." CMMI, in the informative part of the practice, explains that the WBS typically provides a scheme for organizing the work in logical units, called work packages. The Task Coach project does not have a WBS. I guess a very abstract version of a WBS would contain top-level work packages like: develop new features, fix bugs, release software, write documentation, and provide user support. However, we haven't documented this, so I guess this practice isn't implemented.

The second specific practice (SP1.2) of PP reads "Establish and maintain estimates of the attributes of the work products and tasks." The idea here is to estimate the size of work products and tasks, and then use those size estimates as a basis for estimating resource requirements (described in PP SP1.4). However, since this is a project with only volunteers (committed volunteers, but volunteers still), our resources are basically fixed. We also have no fixed deadlines, so there is no immediate need to make these estimates. Anyhow, this practice is not implemented.

The third specific practice (SP1.3) says "Define the project lifecycle phases on which to scope the planning effort." I guess the lifecycle phases of Task Coach are: developing new features, followed by bug fixing (we're not producing bug free software, yet :-) These phases usually overlap, i.e. while bugs are fixed in the latest x.y version, resulting in release x.y.1, x.y.2, etc., work starts on x.y+1. This is not explicitly documented. Again, this practice is not implemented.

The fourth specific practice (SP1.4) of the first PP goal reads "Estimate the project effort and cost for the work products and tasks based on estimation rationale." We don't estimate effort and cost. Practice not implemented.

Since all four practices of the SG1 of PP are not implemented, the goal is not achieved.

The second specific goal (SG2) of PP requires that "A project plan is established and maintained as the basis for managing the project." There are seven specific practices that CMMI expects us to implement to reach this goal.

The first specific practice (SP2.1) of SG2 is "Establish and maintain the project’s budget and schedule." The Task Coach project has no budget, other than the time its developers and other volunteers put into it. We do have an implicit schedule of frequent releases. This is evidenced by the 117 releases in 5,5 years (assuming I counted correctly). However, I am not sure this counts as an established schedule. Practice partly implemented at most.

The second specific practice (SP2.2) is "Identify and analyze project risks." We don't do this.

The third practice (SP2.3) reads "Plan for the management of project data." Like most open source projects, we keep almost all project data in on-line repositories, see the discussion of Configuration Management. Practice implemented.

SP2.4 says "Plan for necessary resources to perform the project." Project resources include labor and equipment, materials and methods. Labor is a given. Other resources such as our Subversion repository, bug tracker, email lists, etc., all are present, but haven't really been planned explicitly. Practice not implemented.

In SP2.5 of PP, CMMI expects you to "Plan for knowledge and skills needed to perform the project." We work with the knowledge and skills that are available and do not explicitly plan to acquire knowledge and skills.

The sixth specific practice (SP2.6) of SG2 reads "Plan the involvement of identified stakeholders." We do involve stakeholders, users mostly, via the UserVoice website and the users mailinglist, but there is no explicit plan for this.

The last specific practice (SP2.7) of SG2 expects us to "Establish and maintain the overall project plan content." We don't have a documented project plan so this practice is not implemented.

Of the seven practice of SG2, we haven't implemented the majority so this goal is clearly not achieved.

The third specific goal (SG3) of PP is "Commitments to the project plan are established and maintained." We have already established that the Task Coach project doesn't have a project plan, so it doesn't seem this goal can be satisfied. We look at the three specific practices for this goal anyway.

The first specific practice (SP3.1) for this goal reads "Review all plans that affect the project to understand project commitments." The idea here is that plans for other process areas (e.g. for Configuration Management, Requirements Management, etc.) may affect the project plan. Since we don't have a project plan, this practice cannot be, and is not, performed.

The second specific practice (SP3.2) states that we should "Reconcile the project plan to reflect available and estimated resources." This is the basis for how we work; adapting all activities to the amount of time the developers have/make available for the project. However, we do not capture the reconciliation in a project plan.

The third specific practice (SP3.3) of the third goal of PP reads "Obtain commitment from relevant stakeholders responsible for performing and supporting plan execution." We do have commitment from the two developers as shown by their involvement in the project for more than five years. Commitment of other stakeholders, like translators or documentation writers, is not secured. This is evidenced by incomplete translations and slow progress on writing a Task Coach user manual. Practice partly implemented.

The practices of the third specific PP goal are only partly implemented, so this goal is not achieved.