Tag: Planning

Project Management Best Practices: Estimating the Work

Written by Karl Wiegers on April 4, 2012. Posted in Articles. 3 Comments on Project Management Best Practices: Estimating the Work

Apr4_FeatKarlW_11427381_XS Parts 1 and 2 of this series presented practices that are useful and effective for laying the foundation for a successful project and planning the project. In this article, adapted from my book Practical Project Initiation, I’ll suggest six good practices for estimating the work you’ll have to do to complete they project.

Practice #12: Estimate based on effort, not calendar time. People generally provide estimates in units of calendar time. I prefer to estimate the effort (in labor-hours) associated with a task, and then translate the effort into a calendar-time estimate. A twenty-hour task might take 2.5 calendar days of nominal full-time effort, or two exhausting days. However, it could also take a week if you have to wait for critical information from a customer or stay home with a sick child for two days. I base the translation of effort into calendar time on estimates of how many effective hours I can spend on project tasks per day, any interruptions or emergency bug fix requests I might get, meetings, and all the other places into which time disappears.

If you track how you actually spend your time at work, you’ll know how many effective weekly project hours you have available on average. My small software group at Kodak did this for several years, as I described in Creating a Software Engineering Culture(Dorset House, 1996). Tracking time like this is illuminating. Typically, the effective project time is only perhaps fifty to sixty percent of the nominal time team members spend at work, far less than the assumed one hundred percent effective time on which so many project schedules are planned.

Practice #13: Don’t over-schedule multitasking people. The task-switching overhead associated with the many activities we are all asked to do reduces our effectiveness significantly. Excessive multitasking introduces communication and thought process inefficiencies that reduce individual productivity.

I once heard a manager say that someone on his team had spent an average of eight hours per week on a particular activity, so therefore she could do five of them at once. Forty hours per week divided by eight is five, right? In reality, she’ll be lucky if she can handle three or four such tasks. There’s just too much friction associated with multitasking.

Some people multitask more efficiently than others, even thriving on it. But if certain of your team members thrash when working on too many tasks at once, set clear priorities and help them do well by focusing on just one or two objectives at a time.

Practice #14: Build training time into the schedule. Estimate how much time your team members spend on training activities annually and subtract that from the time available for them to work on project tasks. You probably already subtract out average values for vacation time, sick time, and other assignments; treat training time the same way.

Recognize that the high-tech field of software development demands that all practitioners devote time to ongoing education, both on their own time and on the company’s time. Arrange just-in-time training when you can schedule it, as the half-life of new technical knowledge is short unless the student puts the knowledge to use promptly. Attending a training seminar can be a team-building experience, as project team members and other stakeholders hear the same story about how to apply improved practices to their common challenges.

Practice #15: Record estimates and how you derived them. When you prepare estimates for your work, write down those estimates and document how you arrived at each of them. Understanding the assumptions and approaches used to create an estimate will make them easier to defend and adjust when necessary. It will also help you improve your estimation process. Train the team in estimation methods, rather than assuming that every software developer and project leader is naturally skilled at predicting the future. An excellent resource is Steve McConnell’s book Software Estimation (Microsoft Press, 2006). Develop estimation procedures and checklists that people throughout your organization can use.

The Wideband Delphi method is an effective group estimation technique. Wideband Delphi builds on the principle that multiple heads are better than one. This estimation technique asks a small team of experts to anonymously generate individual estimates from a problem description and reach consensus on a final set of estimates through iteration. The outputs from the process include a complete list of project and quality-related tasks and an estimate for each task, in whatever units the team chose (such as dollars, weeks, or labor-hours). Participation by multiple estimators and the use of anonymous estimates to prevent one participant from biasing another make the Wideband Delphi method more reliable than simply asking a single individual for his best guess. Chapter 11 of Practical Project Initiation presents a tutorial on the Wideband Delphi estimation method.

Practice #16: Use estimation tools. Many commercial tools are available to help project managers estimate entire projects. Based on equations derived from large databases of actual project experience, these tools can give you a spectrum of possible schedule and staff allocation options. They’ll also help you avoid the “impossible region,” combinations of product size, effort, and schedule where no known project has been successful. The tools incorporate a number of “cost drivers” you can adjust to make the tool more accurately model your project, based on the technologies used, the team’s experience, and other factors. You can calibrate the tool with your own project data to make it an even better predictor of the future. You can compare the estimates from the tools with the bottom-up estimates generated from a work breakdown structure. Reconcile any major disconnects so you can generate the most realistic overall estimate.

Practice #17: Plan contingency buffers. Projects never go precisely as planned. The prudent project manager incorporates budget and schedule contingency buffers (also known as management reserve) at the end of phases, dependent task sequences, or iterations to accommodate the unforeseen. Use your project risk analysis to estimate the possible schedule impact if several of the risks materialize, then build that projected risk exposure into your schedule as a contingency buffer. An even more sophisticated approach is critical chain analysis, a technique that pools the uncertainties in estimates and risks into a rational overall contingency buffer. Chapter 10 of Practical Project Initiation is all about contingency buffers.

Your manager or customer might view these contingency buffers as padding, rather than as the sensible acknowledgment of reality that they are. To help persuade skeptics, point to unpleasant surprises on previous projects as a rationale for your foresight. If a manager elects to discard contingency buffers, he has tacitly absorbed all the risks that fed into the buffer and assumed that all estimates are perfect, no scope growth will occur, and no unexpected events will take place. Sound realistic to you? Of course note. I’d rather see us deal with reality—however unattractive—than to live in Fantasyland.

To wrap up this series of articles, Part 4 will present several practices for tracking your progress and learning for the future.

Don’t forget to leave your comments below

Karl Wiegers is Principal Consultant at Process Impact, www.ProcessImpact.com. His interests include requirements engineering, project management, peer reviews, and process improvement. His most recent book is a memoir of life lessons titled Pearls from Sand: How Small Encounters Lead to Powerful Lessons.

e2e Project Managers are the Key to Ensuring the Delivery of Strategic Projects

Written by Abid Mustafa on March 28, 2012. Posted in Articles. 6 Comments on e2e Project Managers are the Key to Ensuring the Delivery of Strategic Projects

Companies spend a lot of time and effort establishing PMOs and devising project methodologies that enable them to deliver their strategic initiatives. Often, such initiatives span the length and breadth of the organization, are complex in nature, and are extremely cross-functional in their implementation. It is common for such projects to run across three domains: commercial, technology and support. This poses a great challenge for executives in appointing the right type of project manager to take the helm of responsibility and delivery, which naturally leads to a typical discussion about how such projects should be organized. Figure 1.0 illustrates a common project organizational chart that is used to deliver end-to-end (e2e) initiatives.

Figure 1.0 A line project manager leading an e2e project

Executives quickly realize (some after repeated failure) that existing project managers that reside in line functions are limited in their ability and knowledge to deliver initiatives that run e2e. The various models that are available include the following.

Line project managers to run e2e initiatives

The problem associated with line project managers delivering e2e initiatives is that they possess deep knowledge about their function but run into difficulties when they work in other domains. Additionally, such project managers always suffer from a personality/credibility image and employees in other functions do not take them seriously. For instance, commercial project managers may be apt at ensuring that functions such as products, marketing, sales, legal, etc. are provided with not only the requisite support but also fall in line when required. However, such project managers struggle when dealing with IT, as they do not understand the technical parlance, possess the skills to challenge IT staff, or are even familiar with the working of the internal IT departments with its myriad of vendors. Conversely, similar issues are found with IT project managers. Hence, project delivery becomes fragmented and the overall project experience for the executive team suffers.

Depending on the nature of the project, a common remedy is to appoint two project managers, with one taking the lead and the other providing support. In some companies, the supporting project manager is also referred to as the subject matter expert or SME. This is shown in Figure 1.1.

Figure 1.1 Line project manager supported by a functional project manager in delivering an e2e project

However, this type of arrangement is fraught with leadership issues and project teams can easily become fractured by taking sides with one of the two project managers, thereby jeopardizing the delivery times of the project and potentially leading to further stoppages.

Other companies may seek to bolster the abilities of their line project managers by providing them with extra project management training as well as domain-specific skills. This process can be painstakingly slow and depends upon the maturity of the organization, its budgets and time.

Centralized pool of project managers to deliver e2e initiatives

Another way of delivering e2e initiatives is to establish and nurture a small pool of dedicated e2e project managers who are well versed with all the domains of the corporate business and have excellent project management skills. The centralized e2e pool of project managers should reside within the executive program management office (EPMO) and have the support of the executive team. Figure 1.2 depicts the organizational structure of the project hierarchy.

Abid_Fig_1.2

Figure 1.2 E2e project manager leading the project team

The main advantage of this approach is the perceived neutrality of the e2e project manager, as he or she is viewed as unaligned with a particular department. This, together with the support of the executive team, becomes indispensable in building crosss-functional project teams. Nevertheless, it can be argued that such an approach can take accountability away from the line functions and any failure will be quickly apportioned to the e2e project manager. Concerns of such nature can be overcome by ensuring that accountabilities and responsibilities are clearly laid out at the inception of the project. Executives should be held accountable for the realization of the benefits, whereas the e2e project manager is accountable for the delivery of outcomes and capabilities. The project steering committee should oversee that accountability is correctly assigned and should intervene if any deviation is noticed.

In summary, the appointment of an e2e project manager is essential to ensure that an e2e project is delivered successfully. It is up to executives to decide which approach they should employ when faced with the challenges of e2e projects.

Don’t forget to leave your comments below.

Abid Mustafa is a seasoned professional with 18 years of experience in the IT and telecommunications industry, specializing in enhancing corporate performance through the establishment and operation of executive PMOs and delivering tangible benefits through the management of complex transformation programs and projects. Currently, he is working as a director of corporate programs for a leading telecoms operator in the MENA region.

The Agile Project Manager—Listen to your Spider Sense

Written by Robert Galen on March 20, 2012. Posted in Articles. 4 Comments on The Agile Project Manager—Listen to your Spider Sense

Spiderman_2_Bob I was working with an organization a few weeks ago on a coaching assignment. They’ve been experiencing quite a bit of attrition within their technology teams and the discussion inevitably went to root causes. Several leaders at the client were confused about the drivers behind it.

One of them said that they had sat down with several developers before they left and everything seemed fine. They talked about the developers concerns and tried to address every one. They felt that there were “tuned into” the team and were trusted. They just couldn’t understand why folks were leaving without giving them an earlier warning…and more importantly, a chance to address their concerns.

Here’s another interesting ‘twist’ to the plot.

They had recently run an employee survey and the entire technology team seemed happy with their salary levels—generally feeling as if they were competitively compensated. So, everyone within the general management structure of the company took that “off the table”.

However and here’s the “Spider Sense” part, the technology leadership team at the company knew the following:

Local hiring for software talent was ‘hot’ and the company was an attractive target because of the talent of their engineers. The company was viewed as a high-growth startup.
Several key ex-employees had poached multiple engineers to their new organizations. This had been significantly on the increase over the past year.
In all cases when departures were made, it was heard through the ‘grapevine’ that money was a significant factor. And the staff, while fairly paid, were not paid at a “premium rate” sufficient to compete in the hot local compensation market.

So as not to belabor it, the teams were telling leadership that compensation was not an issue. Yet, team members were leaving for significant compensation increases. Was compensation an issue?

From a raw, surface level data perspective, no.

From a an astute technical leader reading the landscape and their local environment perspective, leveraging their observations, knowing their teams, and finally…using their spider sense, the answer is a resounding YES!

The company will continue to lose people until it does something about their lack of compensation competitiveness—amongst probably other adjustments. It may not be the only challenge they face, but it’s certainly one of the “root causes” related to attrition.

Where was I going with this?

So what’s the point and how is it relevant to the Agile Project Manager?

Many naïve and inexperienced agile project managers react to the surface data that they are exposed to in their projects and teams. There’s usually plenty of it going on and it usually keeps their day filled with escalations, follow-ups, actions, and goals. It often is hectic and ‘feels’ as if you’re well-supporting your team & project.

And there’s nothing inherently wrong with this. However, what if the “surface data” isn’t telling you the whole story or the truth. What if there are other undercurrents that you should be paying attention to. And what if those undercurrents are the “root cause” of your team & project challenges and success barriers? Or they are the very things standing between your team’s ultimate improvement, execution excellence, and delivery success?

I liken this sensitized listening to project undercurrents as developing your spider sense. It requires you to read the landscape, listen to the pulse of your team and project, and ultimately putting the pieces together based on your experience and judgment. It requires you to hear the unspoken and see the invisible and sense danger wherever it lurks.

It requires boldness and courage, because often the data isn’t supporting your investigations—so you’re often going it alone on your instincts. So, what are some of the things you can do to develop your own spider sense? I’ll explore a few areas here, but surely the list isn’t intended to be exhaustive.

Listen to what’s NOT being said…

Your team is working incredibly well together. Everyone gets along and is quite nice to one another. During every sprint the team struggles, but within each retrospective nothing crucial comes out for improvement. From the teams’ perspective and from the immediate surroundings, nothing strikes anyone as needing adjustment or repair.

Yet you get the sense that folks are unsettled. Team members are often frustrated with each other and have a general lack of attention to quality or detail across the team. In meetings, only parts of the team engage—usually only 1-2 of the loudest individuals. Everyone else is simply along for the ride. The team also doesn’t seem appreciative of one another—never thanking each other for help or their efforts.

In this case, the team probably lacks the trust and courage to confront their own performance and hold each other accountable. So what’s not being said is—congruent feedback and passionate debate. As an agile project manager, you’ll need to look for ways to improve the teams trust and engagement—perhaps levering your retrospectives as the place for crucial conversations.

Lack of Continuous Improvement

It’s a strong potential anti-pattern in many agile teams that they stop improving. Sure, when they’re just beginning or converting to agile they often show significant improvement and results. But over time, they flatten out and simply start mailing in their results.

Don’t get me wrong, they’re still a very high performing team that is delivering on their promises. But they’re not improving, nor are they ‘stretching’ in their sprints or taking risks. Often these teams show very little quality, execution, throughput, or innovation improvement over time. But they’re not regressing either.

So you need to look for complacent teams and try to look under the covers to see what might be the root cause. Often I see leadership mucking things up in teams—subtly taking away some of their empowerment. Burnout is another frequent cause and yes, you can burn out agile teams! Another factor might be the product organization not providing inspiration aligning the teams work towards business goals. Regardless, you spider sense is tingling and you need to explore further and devise adjustments.

Product Organization Dysfunction

Too often organizations expect teams to simply “suck it up” and give it their all for a paycheck and for the company. Today’s brilliant technologist and engineers are not motivated solely by the money. They want to work on compelling products that delight their customers. They are attracted to product visionaries that are inclusive of their teams. They want to work on great products and they want to be part of the organizations overall success. In a word, they want to work on things that…matter.

In this case your spider sense should focus on how compelling the business is within your teams. If they’re treating your teams like commodities, then you must challenge this complacency and pull someone in to inspire the team by explaining why what they’re doing is important.

One aspect of this sense is looking inside yourself as the measure. Are you excited about your projects, the potential, the meaning, and the impact they will make within your company? Are you excited about the difference they will make to you customers? Do you find yourself jumping out of bed in the morning and impatient to get to work? If your answers to these questions are less than stellar, then use your own feelings as a guide on what needs to be done.

Management Dysfunction or They’re not listening…

One of the more insidious patterns that I’ve seen in teams is that leadership is not effectively listening to the team nor taking action. It is perfectly feasible in my entry example, that team members early on shared their compensation concerns with management. But what did management do with that information? If they didn’t respond quickly enough or significantly enough, then the teams would feel that “leadership” wasn’t taking their concerns seriously.

You see, it’s not just about effective listening. Nor is it about taking small actions or providing excuses. It’s really about those and then taking “appropriate action – fast, timely, well-apportioned, and impactful” that tells your teams that you are truly listening to their concerns AND that it’s worthwhile top them taking the risk to communicate them.

So you’ll want to pay attention to how leadership ‘listens’ to your teams and across the organization. Do they truly listen deeply? Do they plan actions to address impediments and concerns with the team? And do their actions, by and large, align with the needs of the team? Meaning they’re appropriately significant.

I’m not implying that every team-raised issue needs to be attended to. But by and large, your teams need to feel as if the organization cares and is listening—or they will simply stop telling you the truth.

Trust your “Gut” & your “Common Sense”

These final two areas are my guiding light when it comes to my spider sense.

I often go with my gut feelings in decision-making. They’re based on my experience and pattern matching abilities to team and project dynamics that I’ve seen before. They often focus what I’ve been observing and condense it into a singular sense or feeling.

For example, I’ve made three catastrophic hiring decisions in my career. And in all three cases, my ‘gut’ was telling me no, but my head was caught up in bringing them aboard to ease my burden. In all three cases, I ignored my gut feelings. I’ve never done that again.

And then there’s common sense.

There’s an expression in the southern United States regarding pigs. I’ll paraphrase it—if it looks like, sounds like, and smells like a pig…it’s probably a pig. Too often we complicate things. We try to gather too much data and create a too complex landscape. The company I alluded to in my opening was doing that. When they analyzed their attrition, they thought they had between 10-15 factors that were driving it. And that the factors were independent or unrelated.

But when you peeled through the data and got to an honest root cause, there were only 3 primary factors that were driving attrition—money, the technical challenge of the work, and the company’s product vision. And I strongly suspect their common sense and gut feelings aligned with those three areas.

Wrapping Up

As an agile project manager, I want you to start leveraging your instincts, experience and skill in gathering the ‘smells’ within your teams. Just because they’re self-directed, it doesn’t mean they don’t need your experience and help in guiding them through challenges.

Quite often you’re in a unique position to see the forest for the trees and sort of pull things together.

But as I alluded to earlier, it will often be risky and take courage. Everyone will be off barking in the direction of obvious challenges, while you’re guiding them to look in another direction. But don’t be deterred. As that old “Web Slinger” learned long ago…you need to trust your Spider Sense!

Don’t forget to leave your comments below.

Top-down or Bottom-up – Either-or or Both

Written by George Pitagorsky on March 14, 2012. Posted in Articles. 4 Comments on Top-down or Bottom-up – Either-or or Both

Whether the context is planning, requirements definition, or design, the issue of whether to take a top down or bottom up approach and which to take first is relevant.

Different People Think Differently

The question is about how people think and perceive the world and how they go about analyzing the world they perceive. While there is no one right way, there are arguments for taking a top-down approach first and then selectively going down into the details.

On a recent project, working with the definition of program and project scope, one influential stake holder took the position that for the sake of time, the team not spend time on defining the big picture but instead to start with one very important part and work outward from there to ultimately define the full system.

An alternative position was to take some effort to describe the system as a whole and then, once the major components and their relationships were known, to choose what to focus on next in terms of detail.

Some look at things from a top-down perspective, naturally seeing the big picture and how it works. Details are not necessarily their ‘thing’ but they must acknowledge the value and critical importance of details.

Others take a purely bottom-up approach, focusing only on the immediately relevant parts and either devaluing the big picture perspective or seeing it as something that comes out of the knowledge of the details.

Need for Both

There is need for both top-down and bottom-up perspectives and for people to flex their thinking to apply each in keeping with the need.

The big picture person who doesn’t value the effort required to address the details and the detail oriented person who fails to see the importance of the big picture are both detriments to optimal performance.

What is the proper balance? How much time and effort is needed to describe the big picture? What is the value proposition?

For one thing, a top-down perspective defines the context within which a project or system exists. Here we’ll define the word ‘system’ as a bounded collection of inter-operating objects and processes. Anything can be described as a system.

Practically speaking, every system exists within a higher order system and interacts with other systems. For example, an activity exists within a project, a project within an organization; an IT application exists within a business process and within a technology environment.

Small Investment for a Big Pay-off

That is why it is important to see the big picture before diving into the details or leaping into action. Without a clear sense of the big picture one runs a risk of unnecessarily disrupting the higher order system. Without a sense of the big picture one is likely to miss opportunities to plan or design optimally. Risks may be overlooked. Opportunities to build in flexibility and enable future expansion may be missed. Decisions are likely to be made with insufficient knowledge of their results.

Happily, a big picture perspective can be obtained in a relatively short time if it is done correctly. Correctly means visualizing the whole and breaking it down into a relatively small number (3 – 5 or so) of parts (activities, objects, components, etc.) that completely include all aspects of the system. Usually a breakdown of these into a second level of detail is needed to validate the top level and get enough definition to engage the detail oriented people and enable effective analysis.

Once this is done, risk analysis, estimating, high-level design and communication with senior level management can be accomplished before diving into next levels of detail, selectively based on priorities.

Avoid Unnecessary Conflict

It is important to avoid unnecessary conflict between big picture and detail oriented people. Often detail oriented people think that it is necessary to describe all the details in order to understand the whole. While there is some validity to that idea, one can get a sufficient understanding of the whole without knowing all the details. The big picture thinkers must be open to adjusting their ‘model’ of the system as details are defined that raise issues regarding the validity of the model. They must acknowledge that the system is not fully known until the details are defined.

With this in mind, a team can embark on a project or program that progressively elaborates the plan and the definition of the product over the course of project life. They can be careful to avoid wasting time by doing too much top down planning or by not doing enough and thereby discovering issues and risks randomly along the way.

Don’t forget to leave your comments below.

Project Management Best Practices: Planning the Project

Written by Karl Wiegers on February 29, 2012. Posted in Articles. 1 Comment on Project Management Best Practices: Planning the Project

Lamp_head_Planning_Lead_article_33052010_XS In Part 1 of this series, I shared four best practices that can help you lay the foundation for a successful project. In this installment, adapted from my book Practical Project Initiation, I briefly describe eleven practices that are useful for project planning.

Practice #5: Write a plan.

Some people believe the time spent writing a plan could be better spent writing code, but I don’t agree. The hard part isn’t writing the plan. The hard part is doing the planning—thinking, negotiating, balancing, asking, listening, and thinking some more. Actually writing the plan is mostly transcription at that point. The time you spend analyzing what it will take to solve the problem will reduce the number of surprises you encounter later in the project.

A useful plan is much more than just a schedule or task list. It also includes:

Staff, budget, and other resource estimates and plans

Team roles and responsibilities
How you will acquire and train the necessary staff
Assumptions, dependencies, and risks
Target dates for major deliverables
Identification of the software development life cycle that the project will follow
How you will track, monitor the project
Metrics that you’ll collect and analyze
How you will manage any subcontractor relationships

Your organization should adopt a standard software project management plan template, which each project can tailor to best suit its needs. You might start with the project management plan template at www.ProjectInitiation.com. Study this template to see what sections would make sense for the types and sizes of projects that you work on. Shrink and adjust it to suit the nature and size of your own projects.

If you commonly tackle different kinds of projects, such as major new product development projects as well as small enhancements, I suggest you adopt a separate project plan template for each project class. The project plan should be no longer or more elaborate than necessary to make sure you can successfully execute the project. One page might suffice in some cases. But always write a plan.

Practice #6: Decompose tasks to inch-pebble granularity.

Inch-pebbles are miniature milestones (get it?). Breaking large tasks into multiple small tasks helps you estimate them more accurately, reveals work activities you might not have thought of otherwise, and permits more accurate, fine-grained status tracking. Select inch-pebbles of a size that you feel you can estimate accurately. I feel most comfortable with inch-pebbles that represent tasks of about five to fifteen labor-hours. Overlooked tasks are a common contributor to schedule slips. Breaking large problems into smaller bits reveals more details about the work that must be done and improves your ability to create accurate estimates. You can track progress based on the number of inch-pebbles that the team has completed at any given time, compared to those you planned to have done by that time.

Practice #7: Develop planning worksheets for common large tasks.

If your team frequently undertakes certain common tasks—such as implementing a new class, executing a system test cycle, or performing a product build—develop activity checklists and planning worksheets for these tasks. Each checklist should include all of the steps the large task might need. These checklists and worksheets will help each team member identify and estimate the effort associated with each instance of the large task he must tackle. People work in different ways and no single person will think of all the necessary tasks, so engage multiple team members in developing the worksheets.

Using standard worksheets will help the team members adopt common processes that they can tune up as they gain experience. Tailor the worksheets to meet the specific needs of individual projects. I’ve used such worksheets when creating eLearning versions of my training courses. They helped me avoid overlooking an important step in my rush to finish the project.

Practice #8: Plan to do rework after a quality control activity.

I’ve seen project plans that assumed every test will be a success that lets you move on to the next development activity. However, almost all quality control activities, such as testing and peer reviews, find defects or other improvement opportunities. Your project schedule should include rework as a discrete task after every quality control task. Base your estimates of rework time on previous experience. If you collect a bit of data, you can calculate the average expected rework effort to correct defects found in various types of work products.

And if you don’t actually have to do any rework after performing a test, great; you’re ahead of schedule on that task. This is permitted in all fifty states and in many other countries. Don’t count on it, though.

Practice #9: Manage project risks.

If you don’t identify and control project risks, they’ll control you. A risk is a potential problem that could affect the success of your project. It’s a problem that hasn’t happened yet—and you’d like to keep it that way. Simply identifying the possible risk factors isn’t enough. You also have to evaluate the relative threat each one poses so you can focus your energy where it will do the most good.

Risk exposure is a combination of the probability that a specific risk could materialize into a problem and the negative consequences for the project if it does. To manage each risk, select mitigation actions to reduce either the probability or the impact. You might also identify contingency plans that will kick in if your risk control activities aren’t as effective as you hope.

A simple risk list doesn’t replace a plan for how you will identify, prioritize, control, and track risks. Incorporate risk tracking into your routine project status tracking. For reference by future projects, record which risks materialized and which mitigation actions were effective. See Chapter 6 of Practical Project Initiation for an overview of software risk management.

Practice #10: Plan time for process improvement.

Your team members are already swamped with their current project assignments. If you want the group to rise to a higher plane of software development capability, though, you’ll have to invest in process improvement. Software project activities should include making process adjustments that will help your next project be even more successful. This means you’ll need to set aside some time from your project schedule for improvement activities. Don’t allocate one hundred percent of your team’s available time to project tasks and then wonder why they don’t make any progress on the improvement initiative.

Some process changes can begin to pay off immediately, but you won’t reap the full benefit from other improvements until the next project. Process improvement is a strategic investment in the organization. I liken process improvement to highway construction: It slows everyone down a little bit for a time, but after the work is done, the road is a lot smoother and the throughput is greater.

Practice #11: Respect the learning curve.

The time and money you spend on training, self-study, consultants, and developing improved processes are part of the investment your organization makes in sustained project success. Recognize that you’ll pay a price in terms of a short-term productivity loss—the learning curve—when you first try to apply new processes, tools, or technologies. Don’t expect to get fabulous benefits on the first try, no matter what the tool vendor or the consultant claims. Instead, build extra time into the schedule to account for the inevitable learning curve. Make sure your managers and customers understand the learning curve and accept it as an inescapable consequence of working in a rapidly changing, high-technology field.

We’ll look at several practices for estimating the work in the next article in this series.

Don’t forget to leave your comments below.