Author: Elizabeth Larson

Elizabeth Larson, PMP, CBAP, CSM, PMI-PBA is a consultant and advisor for Watermark Learning/Project Management Academy, and has over 35 years of experience in project management and business analysis. Elizabeth’s speaking history includes keynotes and presentations for national and international conferences on five continents. Elizabeth has co-authored five books and chapters published in four additional books, as well as articles that appear regularly in BA Times and Project Times. Elizabeth was a lead author/expert reviewer on all editions of the BABOK® Guide, as well as several of the PMI standards. Elizabeth enjoys traveling, hiking, reading, theater, and spending time with her 6 grandsons and 1 granddaughter.

Lessons Learned On Jury Duty Part 2 – Communicate Complete Project Scope

Written by Elizabeth Larson on November 20, 2013. Posted in Articles. 4 Comments on Lessons Learned On Jury Duty Part 2 – Communicate Complete Project Scope

In Part 1 of this jury duty blog I discussed how when called to serve for jury duty, I had no idea that so much of my time would be spent waiting for something to happen. I compared this wait time to the frustration many of our business stakeholders experience waiting for their end product. In Part 2 I will examine the importance of understanding and communicating the whole project scope.

Communicate the scope before tasks.

When we reported for jury duty, we were told to wait in a large room with over a hundred other potential jurors. We were shown a video about the jury process with high-level tasks, but not the scope of our service. It would have been helpful to know the scope of our involvement if we were selected, such as jury panel selection, security screening, jury questioning (voire dire), jury selection, presentation of evidence, deliberation, and dismissal. Such scope information would have given me the big picture and would have helped set my expectations.

So what is scope? We have found in our project management and business analysis training courses that there is a great deal of confusion between tasks and scope. We often think of the Work Breakdown Structure (WBS) as a list of tasks, not a hierarchy of deliverables, and we assume scope includes all the tasks that will be completed on the project. Scope is not the activities that are performed, but rather the deliverables that are produced. Scope is comprised of things, of outcomes– nouns not verbs.

On our projects we often focus on tasks before we understand the scope. We look at the end date and try to figure out the quickest path to get there—without always spending enough time getting agreement on what will be waiting for us at the end of the journey. There are lots of compelling reasons for this. For example, our sponsor and business stakeholders often provide not only the solution, but also the end date. So we question the value of spending time defining the problem, determining what solution best solves that problem, and how long that solution will likely take to build. Although we understand the risks of not meeting stakeholder expectations, of focusing on getting the tasks done on time, we often lack the courage to influence our stakeholders to step back and do the best thing for the organization, which is to articulate the problem and determine the scope of the solution.

Communicate the scope of the project, not just the scope of the end product.

On most of my projects I have gotten sponsor agreement on the scope of the product. It was always clear what we were going to deliver, which in my case it was software. However, I made the mistake of “not bothering my sponsor with details” related to the project management and business analysis deliverables. Sure, we created project management artifacts such as the WBS, risk plan, activity list, and the estimates, as well as business analysis artifacts like process, use case, and data models, and the business requirements document to name a few. However, by omitting the “details,” business stakeholders were largely unaware of the massive amount of work that went into getting the software into their hands.

Scope on Agile projects.

One of the many aspects of Agile projects that I find appealing is the concept of transparency. Informing stakeholders is fundamental to and built into the Agile processes. Among the techniques used to promote transparency is the team wall, which is visible for everyone in the organization to view.

Included on the team wall is the product scope. Although we don’t often use the word “scope” on an Agile project, and although the scope can change after each iteration, it does exist. Scope on Agile projects is usually comprised of what are called user stories. These stories are high-level requirements often written to show the role of the end user, their goal, and the benefit to them. These stories are arranged in three columns or groups, including those that haven’t been started, those in progress, and those that have been completed.

I can only imagine the advantage to potential jurors if the scope of the jury “project” were transparent and if the process were handled in a more agile fashion. Let’s say, for example, the pending court cases were posted on a “team” wall. The scope of each case would be laid out like an Agile project, with the pending cases in one column, cases in-progress would be in another column, and those completed for the week in a third column. The entire scope of each case would be created, not just the scope related to the jury panel. As new information became available, the team wall would be updated. When the jury panel was called, resources would be assigned to the case or “project,” and the team wall would reflect these assignments.

Perhaps I should suggest this approach. But I wonder which government official would listen.

So, the second lesson learned while on jury duty is the importance of first informing stakeholders what the project will deliver before telling them how it will be done Stay tuned for Part 3 in which I will talk about communicating updates.

Don’t forget to leave your comments below.

Lessons Learned on Jury Duty Part 1 – Why Do We Have To Wait So Long?!

Written by Elizabeth Larson on October 23, 2013. Posted in Articles. 3 Comments on Lessons Learned on Jury Duty Part 1 – Why Do We Have To Wait So Long?!

The reality of a jury trial is different from what we see on TV or read in books, where the action moves quickly towards the acquittal or conviction of the defendant. On TV the opening arguments, the witness interrogation, and the closing arguments are all pertinent and exciting. Of course, on TV and in books trials are filled with action, with both sides winning points, stumbling, and articulating coherent and often poignant arguments. Oh, the fast-paced drama of it all.

So when I was summoned for jury duty, my expectation was that while there might be some down time waiting to be selected for a jury panel, once picked, things would move along quickly. Reality, not surprisingly, proved quite different. Perhaps some trials are filled with drama, interesting cross-examinations, and surprise endings. But my experience as a jury panelist was, for the most part, all about waiting.

What business analysis and project management lessons, then, can we learn from waiting? Here is the first one—remember that our stakeholders are waiting, too. Years ago the sponsor of a large project I managed handed me a Dilbert cartoon, the gist of which was that the less we know about something, the less amount of time we expect its development to take. My sponsor was telling me that he recognized the trap he was falling into–that because he did not understand the complexities of software development, he couldn’t imagine how it could take so long to develop the new application.

During jury duty, after 36 of us had been selected as potential jurors for a criminal trial, we were escorted outside the assigned courtroom to wait until we were called. Someone verbalized his frustration with the process. “What a waste of our time,” he complained. “No doubt the judge is having a martini lunch,” and so on. When we were finally seated in the courtroom, the judge explained the rules we were to follow and immediately dismissed us for a 25 minute break. The person who seemed frustrated before became infuriated. He poured out invective against all lawyers, court clerks, court officials, and public servants. It seemed to me, though, that there were several possibilities for the delay. None of us potential jurors knew what was happening behind the scenes, but that did not mean that there was no activity. It simply meant that we were unaware of what those activities were.

Most stakeholders don’t understand our processes and how long it takes to develop the end solution. After meeting with a business analyst or project manager, our stakeholders are often left to wait. We do our business analysis or project management work while they wait. We’re busy. The development team is busy. The product owner, if there is one, is busy. But the end users, having no idea of the complexities we face, just might be wondering what we’re doing and why they can’t have their end product sooner.
I worked on a project with a full-time product owner assigned, a retail buyer who was lent to us for the duration of the project. After spending a week collocated with us, she exclaimed, “I wish all the buyers could spend time in IT. I had no idea things were so complex! No amount of training in being a BA or PM could have prepared me for how much work is involved in getting the requirements and developing the system. I’m beginning to understand why things take so long.

Without training our SMEs or product owners to actually be business analysts or project managers, what can we do? One thing we might try is to offer our stakeholders the opportunity to spend time in our work areas. Offer them the chance to observe us. Throughout my career, both as a BA and a PM, I have learned invaluable information when I have been able to observe stakeholders working in their areas. Observation has provided an opportunity to better know some of my stakeholders. It has been a way not only to build trust, but get information I could not obtain in any other way. It’s been a chance to learn about work-arounds, as well as issues and frustrations end-users encounter with their systems. It’s one of the best ways I know to build trust while learning about the “as-is.”

When stakeholders spend time with us, observing us while we do our work, they have an opportunity to get a glimpse of our work from another perspective. The wider their understanding and the more complexities they observe, the greater their patience and acceptance are apt to be. By providing them an opportunity to attend all the non-elicitation meetings, to be present when we develop/review data, process, and use case models, to listen as we interact with and answer questions from other team members like the project manager and the technical people, we are providing a viewpoint that few people outside the development team have, and it’s a glorious way to build understanding and trust. So the lesson learned is the importance of trying to empathize with our stakeholders’ likely frustration with the waiting involved in their projects. Stay tuned for the next blog in which I will discuss the second lesson I learned from jury duty, the importance of communicating the whole project scope.

Don’t forget to leave your comments below.

The Courage to Scribe – 42’s Trusted Advisor

Written by Elizabeth Larson on May 15, 2013. Posted in Articles. 4 Comments on The Courage to Scribe – 42’s Trusted Advisor

Larson May15Article Recently I saw the movie “42,” based on the true story of Jackie Robinson, who in 1947 bravely fought custom, bigotry, and violent hostility to become the first African American to play major league baseball. His courage came from his inner strength which allowed him to withstand with dignity the cruel behavior from fans, other team managers and players, and at first some of his own teammates.

As I watched the movie, I was equally taken with the story of Robinson’s “scribe,” Wendell Smith. Also an African American, Smith bravely fought many of the same obstacles as Robinson, but not as visibly, to become a respected sports writer who in 1994 was posthumously inducted into Baseball’s Hall of Fame.

Wendell Smith introduces himself to Robinson early in the movie as Robinson’s “Boswell,” a reference to James Boswell, the biographer of the 18th-century writer, Samuel Johnson. In his Life of Johnson, Boswell chronicles his conversations with Johnson written on their travels together. Like Boswell, Smith chronicles his travels with Robinson. The movie describes the relationship between these two black men struggling to do what each does so well; Robinson to play baseball and Smith to depict the fight to be able to play the game.

From the beginning, Smith establishes his role not only as “scribe,” but also as trusted advisor. He warns Robinson about the difficulties facing the baseball player. He describes probable situations and provides advice on how Robinson should respond. In preparation for those difficulties, Smith gives Robinson an abundance of advice not related to playing baseball, but how to react to the physical and verbal abuse he is likely to encounter. As is common with decision-makers when confronted with advice, Robinson often views the advice as well-intentioned but ill-conceived, so he often pleasantly ignores it, usually to his detriment.

Sometimes, however, Robinson reacts hostilely. Smith, who has also suffered race-related indignities throughout his career, reminds Robinson of the courage needed to succeed. As the trusted advisor, he encourages Robinson to use his strong moral character to avoid reacting violently to violence.

From HBO’s Game of Thrones, to Sam Gamgee in the Lord of the Rings trilogy, trusted advisors literally and figuratively take their life in their hands when providing advice that is clearly in the best interest of the decision-maker, but equally unsought and unwanted. Their advice is often neglected at best. At worst, decision-makers react with anger, or in the case of tyrants, even death. Yet despite the physical and/or emotional danger, trusted advisors do not often get much recognition. Writing about Smith, a Los Angeles Times post poignantly reminds us that “As Jackie Robinson was making history, Wendell Smith wrote it. Many fans remember Robinson and his struggle, but few remember Smith, who sat in the stands typing on a manual typewriter writing about integration on the field, while being barred from the press box because he was black.”

So what does all this have to do with the BA both as scribe and trusted advisor?

As with Smith, shunted off to the stands, we scribes are often shunted off to the back of the room. In virtual sessions, scribes are often forgotten and not even introduced. After the workshops, participants tend to remember who facilitated and participated, but not who scribed. Yet we scribes are, after all, the ones who have the greatest opportunity to create structure from chaos. Scribing requires us to actively listen, absorb, synthesize a great deal of information, and structure elicitation results, such as requirements, issues, workarounds, decisions, etc., into documentation that can be easily read, understood, and confirmed.

As scribes who are also trusted advisors, we often courageously go out on a limb by articulating the need for the role of scribe in organizations which don’t see the need, working with the project manager to account for scribing tasks in the project, and ensuring that the elicitation activity results are documented ethically. In addition, we need to speak up and be heard when remaining silent could jeopardize the accuracy of the documentation. As trusted advisors, then, we need to work behind the scenes to ensure that the organization provides strong, experienced skilled scribes.

Secondly and importantly, we may not feel like we’re in the center of requirement activities, but we really are. What will be remembered is dependent on the job we do scribing. Just as Smith “accompanied Robinson throughout his first major league season, creating his image, reporting his words and crusading for his rights,” we scribes accompany the facilitator, make sense of often rambling and contradictory discussions, while “crusading” always for the right thing for the project and for the organization.

Don’t forget to leave your comments below.

Bill Plaschke, http://www.latimes.com/sports/baseball/mlb/dodgers/la-sp-0414-plaschke-20130414,0,3199706.column, April 14, 2013, viewed on April 14, 2013.

2013 Trends in Business Analysis and Project Management

Written by Elizabeth Larson on January 23, 2013. Posted in Articles. 6 Comments on 2013 Trends in Business Analysis and Project Management

Larson FeatureArticle Jan23 The close of one year tends to make one reflect on what has occurred in the past year and ponder the future. Here we ponder some trends in the Project Management and Business Analysis fields for 2013. This year we want to concentrate on trends for 2013 relating to an emphasis on competencies.

As people become skilled and certified, their base knowledge and abilities are in place. PM, BA, CSM, and BPM practitioners also need to apply their tangible skills to solving problems and helping our organizations achieve their objectives. For example, let’s say Jane knows how to model business processes and how to improve them. But, she may not always get time from stakeholders to understand their process, or establish trust with them to learn the root causes of process problems. She may also run into sharp disagreements about how a new process should be designed or conflicting priorities for what to improve first.

All of these common situations require various “competency” skills, which are often referred to as “soft skills.” We prefer the term “competencies” instead. The trend we’re seeing is that developing so-called “hard” skills isn’t enough. Organizations are now seeing the need to improve their workers’ behavioral-oriented competency skills at the same time.

So here are some competency trends that we see.

Project professionals need to provide advice, not pushback. Several years ago organizations told us that they wanted PMs and BAs to be able to push back when their stakeholders asked for new requirements. Some of these organizations are now seeing that pushing back is one way to avoid being an order-taker, but it is less effective than providing well-analyzed advice. Our prediction is that more organizations will want PMs and BAs to be trusted advisors (sometimes called trusted partners).
Organizations want scribes, not note-takers. Although highly valued in ancient societies, today’s scribes are not always held in high esteem. Many organizations view them as nothing more than note takers, and what’s worse, that’s exactly how many view themselves. The trend that we are starting to see is the recognition that effective scribing is important to the quality of the requirements as well as the project itself. To be an effective scribe, project professionals need to use competencies, such as critical thinking to separate the important from the trivial, the ability to absorb and synthesize a great deal of information and make sense of it, and the ability to present the results in a meaningful way. We are seeing more organizations requiring these skills, particularly of their BAs.
Organizations are beginning to recognize that agile projects require the ability to influence stakeholders.All roles on an Agile/scrum project, in particular the scrum master, the product owner, and the BA, need competencies related to being able to influence. We see some organizations beginning to recognize that each of these roles is distinct (e.g. rather than having the BA be either the product owner or one more member of the delivery team) and each needs to influence in different ways:
1. Scrum masters: need to influence a variety of organizational stakeholders, many of who will have more authority than they. Scrum masters need to remove project roadblocks, which requires influencing sponsors and other executives, financial analysts, vendors, etc.
2. Product owners need to influence other business stakeholders regarding the decisions they make as product owners. Whether prioritizing user stories or reviewing the product increment at the end of an iteration, product owners will need to be effective influencers. More organizations are starting to recognize that although product owners need to make business decisions about the product, they need to get buy-in from others affected by the product. Effective influencing is one of the best ways to achieve this buy-in.
3. Business analysts need to influence just about everyone on an agile project. We are seeing product owners starting to recognize and appreciate the BA’s advice on prioritizing requirements, including impacts, dependencies, risks, etc. Scrum masters are starting to appreciate the BA’s advice on the myriad of issues that relate to requirements, testers on testing the requirements, and vendors on implementing software, to name a few. Again we’re seeing the dawning of this recognition in some organizations.
Organizations are recognizing the cost of virtual teams
The communication overhead of working with offshore resources is getting acknowledged and accounted for more than in the past. Writing requirements for people onsite with whom there is the opportunity for face-to-face communication, as well as shared language and culture, is a leaner process than when writing requirements for people offsite. The cost savings of working with offsite/offshore resources has always been part of the equation for resourcing projects, but the cost overhead of working with offsite/offshore resources hasn’t always been as transparent. It can take many times longer to write requirements for offsite resources. Project professionals are becoming more diligent about identifying the costs incurred to deal with the time zone, language, and cultural differences.
Productivity and speed require the use of disparate and uncoordinated social media and collaboration tools
Until fairly recently, organizations wanted consistency. Consistency in their processes, consistency in their hardware, and consistency in the tools that were purchased to help productivity. The profusion of social media, collaboration, and communication tools continues. We are seeing that team members, particularly virtual, are making use of more and varied applications than ever and not always in a coordinated way. Do team members want a virtual bulletin board? Google it and myriad options come up – many free with few or no decisions required to install. It’s all very fluid. The integration of some of these things happens without even so much as a request. GoToMeeting just appears on a tab in GoogleTalk, for example. Nice. The continued pervasiveness of these apps in an increasingly distributed work environment is driving less standardized toolsets. You use what’s needed at the time, and if you need something you don’t have, click here. It’s free. It’s easy. Job done.
Consensus is giving way to “productive conflict.”
To the extent that the notion of consensus still implies (however erroneously) that everyone gets what they want, organizations are tiring of it. The idea of “productive conflict” holds more appeal. It’s not that organizations are losing interest in consensus, per se, but there is more emphasis on what comes out of the process than the process itself. And productive conflict may not run the risk of getting stuck, as so often happens when groups are trying to get consensus. Does this suggest that there may be some who aren’t in agreement? Maybe. But the trend we’re seeing is more organizations willing to pay that price in order to move forward.

Don’t forget to leave your comments below.

Andrea Brockmeier, PMP is the Client Solutions Director for Project Management at Watermark Learning. She has 20+ years of experience in project management practice and training. She writes and teaches courses in project management, including PMP® certification, as well as influencing skills. She has long been involved with the PMI® chapter in Minnesota where she was a member of the certification team for over eight years. She has a master’s degree in cultural anthropology and is particularly interested in the impact of social media and new technologies on organizations and projects.

About the Authors

Elizabeth Larson, PMP, CBAP, CSM, PMI-PBA is Co-Principal and CEO of Watermark Learning and has over 30 years of experience in project management and business analysis. Elizabeth’s speaking history includes repeat presentations for national and international conferences on five continents.

Elizabeth has co-authored five books on business analysis and certification preparation. She has also co-authored chapters published in four separate books. Elizabeth was a lead author on several standards including the PMBOK® Guide, BABOK® Guide, and PMI’s Business Analysis for Practitioners – A Practice Guide.

Richard Larson, PMP, CBAP, PMI-PBA, President and Founder of Watermark Learning, is a successful entrepreneur with over 30 years of experience in business analysis, project management, training, and consulting. He has presented workshops and seminars on business analysis and project management topics to over 10,000 participants on five different continents.

Rich loves to combine industry best practices with a practical approach and has contributed to those practices through numerous speaking sessions around the world. He has also worked on the BA Body of Knowledge versions 1.6-3.0, the PMI BA Practice Guide, and the PM Body of Knowledge, 4th edition. He and his wife Elizabeth Larson have co-authored five books on business analysis and certification preparation.

10 Steps to Creating a Project Plan

Written by Elizabeth Larson on May 17, 2012. Posted in Articles. 215 Comments on 10 Steps to Creating a Project Plan

One of the critical factors for project success is having a well-developed project plan. This article provides a 10-step approach to creating the project plan…

not only showing how it provides a roadmap for project managers to follow, but also exploring why it is the project manager’s premier communications and control tool throughout the project.

Step 1: Explain the project plan to key stakeholders and discuss its key components. One of the most misunderstood terms in project management, the project plan is a set of living documents that can be expected to change over the life of the project. Like a roadmap, it provides the direction for the project. And like the traveler, the project manager needs to set the course for the project, which in project management terms means creating the project plan. Just as a driver may encounter road construction or new routes to the final destination, the project manager may need to correct the project course as well.

A common misconception is that the plan equates to the project timeline, which is only one of the many components of the plan. The project plan is the major work product from the entire planning process, so it contains all the planning documents for the project.

Related Article: The Project Plan: How Much Detail is Enough?

Typically many of the project’s key stakeholders, that is those affected by both the project and the project’s end result, do not fully understand the nature of the project plan. Since one of the most important and difficult aspects of project management is getting commitment and buying, the first step is to explain the planning process and the project plan to all key stakeholders. It is essential for them to understand the importance of this set of documents and to be familiar with its content, since they will be asked to review and approve the documents that pertain to them.

{loadmodule mod_custom,ad 300×100 Large mobile}

Components of the Project Plan Include:

Baselines. Baselines are sometimes called performance measures, because the performance of the entire project is measured against them. They are the project’s three approved starting points and include the scope, schedule, and cost baselines. These provide the ‘stakes in the ground.’ That is, they are used to determine whether or not the project is on track, during the execution of the project.

Baseline management plans. These plans include documentation on how variances to the baselines will be handled throughout the project. Each project baseline will need to be reviewed and managed. A result of this process may include the need to do additional planning, with the possibility that the baseline(s) will change. Project management plans document what the project team will do when variances to the baselines occur, including what process will be followed, who will be notified, how the changes will be funded, etc.

Other work products from the planning process. These include a risk management plan, a quality plan, a procurement plan, a staffing plan, and a communications plan.

Step 2: Define roles and responsibilities. Not all key stakeholders will review all documents, so it is necessary to determine who on the project needs to approve which parts of the plan. Some of the key players are:

Project sponsor, who owns and funds the entire project. Sponsors need to review and approve all aspects of the plan.
Designated business experts, who will define their requirements for the end product. They need to help develop the scope baseline and approve the documents relating to scope. They will be quite interested in the timeline as well.
Project manager, who creates, executes, and controls the project plan. Since project managers build the plan, they do not need to approve it.
Project team, who build the end product. The team needs to participate in the development of many aspects of the plan, such as identifying risks, quality, and design issues, but the team does not usually approve it.
End users, who use the end product. They too, need to participate in the development of the plan, and review the plan, but rarely do they actually need to sign off.
Others, such as auditors, quality and risk analysts, procurement specialists, and so on may also participate on the project. They may need to approve the parts that pertain to them, such as the Quality or Procurement plan.

Step 3: Hold a kickoff meeting. The kickoff meeting is an effective way to bring stakeholders together to discuss the project. It is an effective way to initiate the planning process. It can be used to start building trust among the team members and ensure that everyone’s idea are taken into account. Kickoff meetings also demonstrate commitment from the sponsor for the project. Here are some of the topics that might be included in a kickoff meeting:

Business vision and strategy (from sponsor)
Project vision (from sponsor)
Roles and responsibilities
Team building
Team commitments
How team makes decisions
Ground rules
How large the group should be and whether sub-groups are necessary

Step 4: Develop a Scope Statement. The Scope Statement is arguably the most important document in the project plan. It’s the foundation for the rest of the project. It describes the project and is used to get common agreement among the stakeholders about the scope. The Scope Statement clearly describes what the outcome of the project will be. It is the basis for getting the buy-in and agreement from the sponsor and other stakeholders and decreases the chances of miscommunication. This document will most likely grow and change with the life of the project. The Scope Statement should include:

Business need and business problem
Project objectives, stating what will occur within the project to solve the business problem
Benefits of completing the project, as well as the project justification
Project scope, stated as which deliverables will be included and excluded from the project.
Key milestones, the approach, and other components as dictated by the size and nature of the project.

It can be treated like a contract between the project manager and sponsor, one that can only be changed with sponsor approval.

Step 5: Develop scope baseline. Once the deliverables are confirmed in the Scope Statement, they need to be developed into a work breakdown structure (WBS), which is a decomposition of all the deliverables in the project. This deliverable WBS forms the scope baseline and has these elements:

Identifies all the deliverables produced on the project, and therefore, identifies all the work to be done.
Takes large deliverables and breaks them into a hierarchy of smaller deliverables. That is, each deliverable starts at a high level and is broken into subsequently lower and lower levels of detail.
The lowest level is called a “work package” and can be numbered to correspond to activities and tasks.

The WBS is often thought of as a task breakdown, but activities and tasks are a separate breakdown, identified in the next step.

Step 6: Develop the schedule and cost baselines. Here are the steps involved in developing the schedule and cost baselines.

Identify activities and tasks needed to produce each of the work packages, creating a WBS of tasks.
Identify resources for each task, if known.
Estimate how long it will take to complete each task.
Estimate cost of each task, using an average hourly rate for each resource.
Consider resource constraints, or how much time each resource can realistically devoted to this project.
Determine which tasks are dependent on other tasks, and develop critical path.
Develop schedule, which is a calendarization of all the tasks and estimates. It shows by chosen time period (week, month, quarter, or year) which resource is doing which tasks, how much time they are expected to spend on each task, and when each task is scheduled to begin and end.
Develop the cost baseline, which is a time-phased budget, or cost by time period.

This process is not a one-time effort. Throughout the project you will most likely be adding to repeating some or all of these steps.

Step 7: Create baseline management plans. Once the scope, schedule, and cost baselines have been established, you can create the steps the team will take to manage variances to these plans. All these management plans usually include a review and approval process for modifying the baselines. Different approval levels are usually needed for different types of changes. In addition, not all new requests will result in changes to the scope, schedule, or budget, but a process is needed to study all new requests to determine their impact to the project.

Step 8: Develop the staffing plan. The staffing plan is a chart that shows the time periods, usually month, quarter, year, that each resource will come onto and leave the project. It is similar to other project management charts, like a Gantt chart, but does not show tasks, estimates, begin and end dates, or the critical path. It shows only the time period and resource and the length of time that resource is expected to remain on the project.

Step 9: Analyze project quality and risks.
Project Quality: Project quality consists of ensuring that the end product not only meets the customer specifications, but is one that the sponsor and key business experts actually want to use. The emphasis on project quality is on preventing errors, rather than inspecting the product at the end of the project and then eliminating errors. Project quality also recognizes that quality is a management responsibility and needs to be performed throughout the project.

Creating the Quality Plan involves setting the standards, acceptance criteria, and metrics that will be used throughout the project. The plan, then, becomes the foundation for all the quality reviews and inspections performed during the project and is used throughout project execution.

Project Risks: A risk is an event that may or may not happen, but could have a significant effect on the outcome of a project, if it were to occur. For example, there may be a 50% chance of a significant change in sponsorship in the next few months. Analyzing risks includes making a determination of both the probability that a specific event may occur and if it does, assessing its impact. The quantification of both the probability and impact will lead to determining which are the highest risks that need attention. Risk management includes not just assessing the risk, but developing risk management plans to understand and communicate how the team will respond to the high-risk events.

Step 10: Communicate! One important aspect of the project plan is the Communications Plan. This document states such things as:

Who on the project wants which reports, how often, in what format, and using what media.
How issues will be escalated and when.
Where project information will be stored and who can access it.

For complex projects, a formal communications matrix is a tool that can help determine some of the above criteria. It helps document the project team’s agreed-on method for communicating various aspects of the project, such as routine status, problem resolution, decisions, etc.

Once the project plan is complete, it is important not just to communicate the importance of the project plan to the sponsor, but also to communicate its contents once it’s created. This communication should include such things as:

Review and approval of the project plan.
Process for changing the contents of the plan.
Next steps—executing and controlling the project plan and key stakeholder roles/responsibilities in the upcoming phases.

Don’t forget to leave your comments below.

Elizabeth and Richard Larson are Co-Principals of Watermark Learning, a project management and business analysis training company. They have over 30 years of industry experience each, and have helped thousands of PM and BA practitioners develop new skills.

They have published numerous articles and papers and have co-written two books together on Requirements Management and CBAP Preparation. Both Rich and Elizabeth are CBAP and PMP certified through IIBA and PMI, and are contributors to the BABOK® Guide, Version 2.0 and the PMBOK® Guide – 4^th edition.