Characteristics

,

To be used effectively, the Linear PMLC model works best with projects that have the following:

• Complete and clearly defined goal, solution, requirements, functions, and features
• Few expected scope change requests
• Routine and repetitive activities
• Use of established templates

Complete and Clearly Defined Goal, Solution, Requirements, Functions, and Features

You first have to have a clear understanding of what the project is trying to accomplish. That originally led to a statement of the project goal, which you and your client developed together. With the goal firmly established, you and the client were able to define exactly what had to be done to achieve the goal. The statement of what had to be done was detailed through a requirements gathering process that listed and documented the functions and features that spelled out the details of what had to be done. If you and the client were convinced of the completeness of the requirements document, then a Linear PMLC model was chosen for the project.

At the risk of being repetitive, I want to stress that the decision that requirements details were complete is a very subjective decision. You will never really know that requirements details were complete. On the other hand, you would probably know that some of the details were not complete or clear.

Few Expected Scope Change Requests

You are not likely to encounter a project that turns out to be totally free of any scope change requests. We live and work in a dynamic environment that is always changing. I have never encountered a change-free project in more than 45 years of managing projects. It would be presumptuous of you and your client to expect that your project will be safe from any changes. If you have any doubt, add a management reserve task to the end of the project schedule and explain to the client how it will be used. If you successfully manage the project according to the initial plan and there are no scope change requests that impact the schedule, the project will end on its originally planned date. If not, you will have a contingency to handle the changes. If you feel there will be numerous changes, but you meet all other conditions for using a Linear PMLC model, you should probably choose some other model. An Iterative PMLC model would be my most likely choice.

Routine and Repetitive Activities

Even though projects are unique, they can still be repeated. Their uniqueness comes from external factors acting on the project, your client, your team, and your organization. If you manage projects that are routine and repetitive, here are some suggestions to make life a bit easier for you and to increase the effectiveness of your management of those projects.

Build and Use a Library of Templates

This is perhaps the most valuable artifact you will generate from repetitive projects. I have helped my clients build and use templates that range from Work Breakdown Structures (WBSs) to parts of WBSs; from candidate risk events lists to detailed risk mitigation plans for a specific risk event, acceptance test criteria lists, vendor solicitation strategies, Request for Information (RFI), Request for Proposals (RFP) and Request for Quote (RFQ) outlines, project notebook outlines, curriculum design, meeting agendas, and the list goes on. If you have a WBS template, it is highly likely that the template also contains duration, resource requirements, project network diagrams, and the schedule to the WBS template. That gives you a start on a big chunk of the project plan. It requires some editing for the specifics of the project plan, but at least you have a start. And you have a start for which there is previous experience.

The next most valuable template will be risk management plans. Not only will the template identify risks for this type of project but also the mitigation plans and a historical record of outcomes.

Building a template library requires very little extra effort. You can start by simply saving in retrievable form any of the documents just mentioned that are produced as part of normal project activities. For some future project, retrieve the document and modify it for use on the current project. Add the modified document to your template library. In time you will build a variety of examples of that type of document. These become your templates. I have found with my clients that a template library has saved them time and reduces mistakes. They are also great training aids. Your Project Management Office (PMO) may already maintain a template library. If it doesn't, suggest that it start one.

But there is a caution here that you need to be aware of. Too many project managers look for silver bullet solutions, and templates can be misused. The degree of fit of a template to a project or partial project must be examined carefully. Expect to modify the template rather than use it off the shelf.

Keep and Post the History of Lessons Learned

This sounds great, but it rarely happens to any benefit. Several reasons are given for not documenting lessons learned on a project, including the following:

• Post-implementation audits are not done.
• Takes too much time to document lessons learned.
• No way to classify lessons for easy retrieval.
• No one is assigned the responsibility.
• The lessons won't apply to my projects.
• Lessons learned are not seen as useful.
• To use lessons learned would reflect badly on my reputation.
• Unbiased information is not forthcoming.
• Teams won't share mistakes and dirty laundry.

Lessons learned are most successful if posted at the time of their occurrence. Waiting until the project is over before these lessons are documented and posted is usually a waste of time.

Lessons learned can provide a powerful development opportunity. Many project managers have tried to collect and post lessons learned on a project for all to take advantage of, but few have succeeded. If you are going to try — and I strongly advise that you do — make sure you have an effective way of neutralizing the excuses listed here.

Keep a History of Estimated and Actual Task Duration

This can be a very simple history or a very complex one. It all depends on its importance to your project management practices. Most organizations would point to their inability to accurately estimate as a major weakness. They need all the help they can get, and I would suggest that their estimation history is a good resource. Here are a few ways I have helped my clients define, create, and maintain their history.

Recall that the first method that most individuals will use to estimate task duration is recollection of having done a similar task in the past and using their own experiences with similar tasks to estimate the duration of the task at hand. That's okay if you have the experience, but if you don't, your next approach will be to draw on the experiences of others. One way to do that is to refer to a recorded history of similar tasks. The trick is to identify and measure the variables that define similar tasks and index the estimates based on those variables. For the task at hand, you will need to know the value of its variables and retrieve the recorded history using that task profile. Some of the variables that you might use to define this task profile are as follows:

• Task category
• Task type
• Estimated task duration
• Actual task duration
• Software environment
• Requested skill level of the person doing the task
• Actual skill level of the person doing the task
• Work environment profile (using a scale of 1 for excellent to 5 for very poor)

Collecting and maintaining such a history file is labor-intensive. You will invest in that labor if improving task duration estimation is critical to your organization. Here are three ways that my clients have used their task history:

• Display a sample of similar tasks and average the actual duration to get an estimate for the task at hand.
• Compile a list of tasks ranked by similarity and choose a duration that fits the history.
• Generate a multiple linear regression model to estimate task duration.

The first two methods are the quickest and easiest. The third is an automated solution and may not produce estimates that are any better than those produced using the first two methods.

Keep a History of Risks, Your Mitigation Plans, and the Results

Risk history, like task duration history, can be a very simple file. The indexing variables might be any or all of the following:

• Risk category
• Risk type
• Risk description
• Mitigation plan
• Actual risk event that occurred
• Result
• Resource person

The team member who is responsible for the risk log will also have the responsibility for maintaining the risk history file. The risk log provides all of the information you need to populate your risk history file. Your PMO might support a risk history service. If it doesn't, ask it to do so.

Use of Established Templates

If used properly, the template library can really cut down on planning time, significantly increase the quality of your project management experience, and decrease the risk of project failure. There are several benefits to using templates, including the following:

• Increases standard practices
• Provides learning modules for new project managers
• Establishes an archive of project artifacts
• Provides input for process and practice improvement programs

Increases Standard Practices

If the templates are seen as valuable, they can become the foundation on which practices are formed. Learning by way of example is supported. As the templates are used, the adopters will find ways to improve them and ultimately improve the processes they support.

Provides Learning Modules for New Project Managers

Templates can be integrated into the classroom and online curriculum as learning aids for training project managers. Because you are using actual templates from the projects in your organization, they will be of maximum benefit to those attending training. They will have immediate application on the job.

Establishes an Archive of Project Artifacts

Artifacts from actual projects provide help to project managers across all Process Groups. Project managers need a simple and intuitive way to access information from past projects and find what will be helpful to them in managing their current projects. The collection of artifacts will grow quickly. That will require a good indexing and retrieval system. One of my clients has established an intake function for submissions to the archives. No one can just add stuff. All proposed submissions must go through the intake function and be screened for acceptability and indexing before they are added.

Provides Input for Process and Practice Improvement Programs

Templates are looking glasses into the Process Groups. They reflect how clients, project managers, and project teams have applied the PMLC models. Some will have done so correctly, others not. So, one of the responsibilities of the person in charge of the archive intake function is to screen contributions for compliance.

Strengths

The strengths of the Linear PMLC model are as follows:

• The entire project is scheduled at the beginning of the project.
• Resource requirements are known from the start.
• The Linear PMLC model does not require the most skilled team members.
• Team members do not have to be co-located.

The Entire Project Is Scheduled at the Beginning of the Project

For those who don't like surprises, this is the ticket. The plan is complete. The project manager and every team member know what has to be done, who will do it, and when it must be complete. There are no surprises — well, you hope not too many, and not too serious ones at that.

Resource Requirements Are Known from the Start

Not only do you know what type of resource is needed but you also know when, for how long, and what that resource is required to do. For people resources you even know the name of the person who will be assigned to the project. That allows you to complete the project budget. You will know what everything will cost and when you need to encumber the funds.

Human resource management and planning can benefit from the Linear PMLC model. Because you know from the existing project plans what skills are needed, by when, and in what numbers, you can compare this against your inventory of skills and when they will be available. The gaps will give you information training and development needs. You have an opportunity to take corrective steps to remove those skill gaps through training or otherwise plan for contracting out your needs.

The career and professional development plans of your staff can also benefit. Knowing what project opportunities lay ahead and what the development needs of your staff are, you can begin to match up possible assignments. While you would like to think that your HR department is on top of this, I really have been disappointed. Most HR management I talk to want a complete solution for all staff and not just a partial solution for project teams. The PMO appears to be a better place for that type of planning and staff development to take place.

The Linear PMLC Model Does Not Require the Most Skilled Team Members

This is the real strength of the Linear PMLC model. Because the project plan is detailed and work packages have been written for some tasks, a person of intermediate skill can do the work with minimal or no supervision. This is a real plus.

Team Members Do Not Have to Be Co-Located

Again, because the project plan is complete, the person responsible for the task can proceed with the work wherever he or she happens to be located. Some added documentation may be required. Outsourcing and the use of offshore developers are also possible alternatives.

There are strategies that you might employ when the development team is located across several time zones. For example, I have done development in the United States and passed the code to Europe and Asia for testing. The following morning, the developers in the United States had tested code at their disposal. So while having a team distributed across several time zones has its management problems, there are also some advantages to this sort of scheduling.

Weaknesses

The weaknesses of the Linear PMLC model are as follows:

• Does not accommodate change very well
• Costs too much
• Takes too long before any deliverables are produced
• Requires complete and detailed plans
• Must follow a rigid sequence of processes
• Is not focused on client value

Does Not Accommodate Change Very Well

The problem is that nearly any scope change request that is approved will create problems with the schedule. The time of the team members who have to process the request and write the Project Impact Statement is time that has to be added to the schedule. That probably results in a delayed completion of the project. That is the lesser of the two problems. The more serious problem is the adjustment to the schedules of every task that was scheduled to occur after the scope change was added to the project schedule. Literally every team member's schedule will be affected. If those schedule changes are too severe, the request might be delayed until much later in the project. I'm sure you can see the potential for adding significant management time just to accommodate the change request.

Costs Too Much

The client won't see any of the deliverables until the 11th hour in the project schedule — when the acceptance test criteria are being checked for requirements satisfaction. Usually there will be problems with acceptance. More work will have to be done, but there is no money available for that work. By that time, most of the money will have been spent.

Takes Too Long before Any Deliverables Are Produced

As I just stated, the client doesn't see any of the deliverables until very late in the project. That leaves no time for change even if the money is available. The project deadline is rapidly approaching, and the team members are scheduled to move on to other project work. This is not a problem in simple projects but all of those have already been done. In more complex projects, any additional work that has to be done to gain client acceptance will take time that has not been planned for and will come at the end of the project. The team members' attention is already turned to their next assignment.

Requires Complete and Detailed Plans

Although this may sound strange, a complete plan may be a waste of time. Before you cast your first stone, let me explain. In my early years as a project manager, I fell into the trap of always requiring complete plans. Unfortunately I don't recall even one of those plans being executed without changes being made. Every change request that is approved requires a revision in the project plan from the point where the change is inserted to the end of the project.

Take a look at how much time is wasted doing all of this replanning. Suppose there are 10 approved change requests in a 12-month project. For the sake of simplicity, also suppose that each change request requires one work day per remaining project month to revise the complete project plan and reschedule the team members out to the end of the project. Each change request is approved at the end of a project month. Table 10-1 calculates the wasted planning time.

WOW! The work scheduled for the last two project months has been replanned and rescheduled 10 times, and you spent 20 project days doing that replanning! Further to the point, notice how much of the project work in the later months of the project isn't even done. Change requests may have rendered some of that work as not needed, yet you spent all that time replanning and rescheduling it.

Table 10-1: Replanning Time

If that doesn't rattle you, how about taking a look at the percentage of team work time that was spent replanning and rescheduling? Suppose the team has five members who each work half time on the project. The project is 48 weeks long, and you have five people working at 50 percent of their time. So, you have 600 person days of resources to complete the project, and you just spent over 10 percent of those days doing replanning and rescheduling. Translate that into project days, and you have just added more than five weeks to the completion date of the project — all non-value-added work time! And you still have to add the work time necessary to deliver the changes.

I hope I have given you sufficient motivation to stop and think about the impact of change on your project plan and the importance of having good scope change controls in place. I don't want you to think that I'm advocating no scope change requests, which would make no sense whatsoever. However, I am advocating good scope control processes.

Must Follow a Rigid Sequence of Processes

You chose to use the Linear PMLC model, so you have to play by the rules. And the rules say no going back. Remember, you chose this model because you didn't expect to have to go back.

Is Not Focused on Client Value

The Linear PMLC model is driven by the need to get the project done on time, within the budget, and according to client specifications. Nowhere does it say that you have to deliver business value. If it should happen that the delivery according to client specification is the cause of business value, then you are okay. Unfortunately I have had many clients tell me that they got what they asked for, but it didn't do what they expected. Go back to the discussion of wants versus needs in Chapter 4, and you'll find an explanation for this.

When to Use a Linear PMLC Model

Projects that have been repeated several times are excellent candidates for a Linear PMLC model. Supposedly you built a library of templates for those repetitive projects. You will have encountered and put plans in place for every identifiable risk. There will be few, if any, surprises. Simple projects of short duration that fall entirely within a single department and use no resources outside of that department are also good candidates for the Linear PMLC model.

Variations to the Linear PMLC Model

Two variations of the Linear PMLC model are worth mentioning. Both are designed to compress the project into a narrower window of time in order to deliver the solution quicker and get product and service to the market or to the end user sooner. They are as follows:

• Rapid Linear PMLC model — This is a client-focused model that delivers incremental functionality with business value in parallel swim lanes.
• Feature-Driven Development (FDD) Linear PMLC model — This is not a client-facing model. Instead it delivers parts of the solution in parallel, technically cohesive increments referred to as feature sets.

These two variations are described in the following subsections.

The Rapid Linear PMLC Model

The Rapid Linear PMLC model occurs frequently in product development projects. Figure 10-2 is a graphical description of that variation. The purpose of this variation is to finish the project as quickly as possible so as to get the deliverables implemented sooner. Usually this is done in response to pressures from marketing for early entry product introductions.

The decision to use this variation must be made during execution of the Planning Process Group. Note that planning is done once in a Rapid Linear PMLC model. The planning goal is to partition the functions and features into independent swim lanes so that the dependencies within each swim lane are high (maximum cohesion) and the dependencies between swim lanes are minimal or nonexistent (minimal coupling). This allows each swim lane to proceed independently of all other swim lanes. That minimizes the additional management time brought about by the parallel dependent swim lanes. If a cross–swim lane dependency exists and something goes wrong in one swim lane, it can adversely impact other swim lanes that are dependent upon it.

Figure 10-2: The Rapid Linear PMLC model

One of the major obstacles to minimal cohesion is resource contention across the dependent swim lanes. Using team members across swim lanes is another area where caution is needed. If one swim lane is delayed, it can delay the availability of a team member to begin work in another swim lane. Don't expect to avoid this resource contention problem altogether in the Rapid PMLC model. It won't happen. You just have to be aware of the risks and do what you can to minimize the impact.

Feature-Driven Development Linear PMLC Model

Feature-Driven Development (FDD) first appeared in Java Modeling in Color with UML by Peter Coad, Eric Lefebvre, and Jeff DeLuca (Prentice Hall PTR, 1999). A more comprehensive treatment of FDD can be found in A Practical Guide to Feature-Driven Development by Stephen R. Palmer and John M. Felsing (Prentice Hall PTR, 2002).

The high-level process view of the FDD Linear PMLC model is shown in Figure 10-3. Note that planning is done only once, so the solution must be known in order to use FDD effectively. A model of the solution is developed and used to create the functional WBS. The functional WBS contains a very detailed list of features. The features list is grouped into similar features and prioritized for development. FDD iterates on the design and building of the groups of features.

Figure 10-3: FDD Linear PMLC model

Much like the Rapid Development PMLC model, the FDD Linear PMLC model prioritizes parts of the solution. But this time it is features-driven. Just as in the Rapid Development PMLC model, you have multiple design/build swim lanes running concurrently in the FDD Linear PMLC model. It differs from the Rapid Linear PMLC model in that the releases consist of groups of features that have a technical relationship to one another rather than a functional relationship to one another. Several feature sets might have to be completed before the client is satisfied that the cumulative features list has enough business value to be released. FDD models might use concurrent swim lanes, sequential phases, or some combination of the two.

Considerations in Choosing a Variation

In choosing between the Rapid Linear model and the FDD model, you need to weigh three considerations.

Decomposing the Project into Parallel and Independent Swim Lanes

The first objective would be to decompose the functionality into independent swim lanes. The fewer dependencies there are across the swim lanes, the easier it will be to schedule resources and work. The likelihood of cross–swim lane scheduling conflicts is reduced as the dependency between swim lanes is reduced.

Swim Lane Cohesiveness

The second objective would be to make the functions or technical features within a swim lane as cohesive as possible. Does the functionality fit together? Does the technical dependency fit together? Do these swim lanes offer business value?

Increased Risk

The work of the project is compressed into a shorter time frame than required by the single–swim lane approach. That causes risk to increase because of such factors as scope change, resource contention, and problem resolution. There is less time to analyze and take action than in the single–swim lane approach. In addition, the opportunities to recover are fewer and more difficult than in the single–swim lane approach.

Adapting and Integrating the Tools, Templates, and Processes for Maximum Effectiveness in Linear PMLCs

To successfully implement either the Rapid Linear model or the FDD model, you have to begin during the construction of your project network diagram. Your objective is to define a sequence of swim lanes where each swim lane contains the functions and features of part of the solution. In total, all swim lanes contain functions and features that combine to provide a complete solution. These swim lanes must have the following properties:

• The functions and features of a swim lane can be built independently of the functions and features of any other swim lane.
• There are no resource dependencies across swim lanes.
• There are no schedule dependencies across swim lanes.
• The total duration of each swim lane must be nearly equal.

If these properties cannot be satisfied, then at least the interactions between swim lanes must be minimized. Although this variation might seem to be very attractive given today's rush to market, some problems will arise.

There are several things to consider in creating such an aggressive schedule. By squeezing the work into a shorter time frame, you must remember that the amount of work has not decreased — it just must be completed in less time. The last parallel swim lane that is complete determines the completion date of the development project. The results of schedule compression are as follows:

• Increased management time to handle intra–and inter–swim lane issues
• Increased likelihood of resource contention
• Potential for overlooking cross–swim lane dependencies
• Less time to recover from a mistake

All of these results contribute to an increased risk of project failure. So if there is pressure to use either the Rapid Linear PMLC model or the FDD Linear PMLC model instead of the Linear PMLC model, assess the complexity and potential risk implications. You might also want to assess the skills and competencies of the project team members and the likelihood that they can adapt to such an aggressive schedule.