Elizabeth Larson, Author at Project Management Articles, Webinars, Templates and Jobs

The Fallacy of SMART Goals

Written by Elizabeth Larson on January 24, 2023. Posted in Articles.

I recently read a news story about how to keep our New Year’s resolutions. The article was about the use of simple time management techniques, the center of which was setting SMART goals. SMART is an acronym that’s been around for decades and stands for goals that are Specific, Measurable, Achievable Relevant, and Time-bound. Sometimes other words are used, such as assignable, realistic, timely, and testable.

It sounds good. It sounds useful. But simplifying time management into an acronym reduces the complexity of managing our projects to a seemingly simple formula, one that can prove frustrating. It reminds me of countless bosses and sponsors I’ve had who said, “Can’t you just tell me when the project will be done? Use SMART goals to help you figure it out!” Don’t get me wrong. I think this acronym is useful as a high-level framework. But if our goals too high-level, we run the risk of never achieving them. It’s just not that easy. Let me give you some examples using a project to build a house.

Specific. What does it mean to be specific? How are specific goals different from measurable or achievable or time-bound goals? In our house-building example house specifications are specific, as the name implies. There are specs for the exterior and the interior. Specs for landscaping, the roof, the plumbing, electrical and so forth. How specific do they need to be? Specs without detail might be helpful as an overview, but not for the actual construction of the house. We need to drill to down for the specs to be workable.

Measurable. To say that the house will be complete in 18 months, for example, is measurable. It’s a good starting point. As the homeowner I can start planning when to put my current house on the market or end my lease, when to get current utilities canceled and the new ones turned on, when to arrange for movers and so forth. But when is done really done? I’ve been told a house was done before the gas was hooked up. I was told a house was done, but movers wouldn’t unload their truck because the floors had been finished too recently. We need to get the detail to make important decisions. And as PMs we need to determine who will decide which measures to use and whether they make sense from a project perspective.

Achievable. Achievable is another one of the squishy terms in the SMART acronym. It’s one of those words that means different things to different project stakeholders. I suspect I’m not the only PM to be told to “just make it happen.” Or “Where’s your can-do attitude?” I can certainly make almost any project happen, but at what cost? How much risk will the organization/sponsor/end users tolerate? Achieving an end quickly might mean making compromises. Who will make those decisions? What about trust and team dynamics? All these components of achievability need to be considered. And that takes time and lots of discussion.

Relevant. I’m not sure I understand what a relevant goal is. There are so many different stakeholders on our projects, some of whom do not find the project or its end product relevant at all. Hopefully it’s relevant to the organization, helping it meet its business objectives. But we all know that’s not always the case. I suspect many of us have worked on someone’s “pet project.” Or have had some stakeholder groups resist implementation. Or have managed projects highly relevant to end users but not to higher levels of management and vice versa. Getting agreement on what is relevant and how the project’s relevancy fits in with all the other projects is no easy task.

Time-bound. This usually means attaching a timeframe to the goal. I struggle with the difference between time-bound and all the other goals. I think they are intertwined. As a PM I worked on projects that were relevant only if they could be implemented in enough time to get goods from sourced locations to retail stores and on the shelves in time for the holiday season. Is that time-bound? Or relevant? Or I suspect, a bit of all the components of the acronym.

Which brings me to my original point. SMART goals are useful as a framework. But the key to time management success is going from a high-level overview to subsequently lower and lower levels of detail. We can certainly start with SMART. But we need to drill down to really achieve our goals.

Best of PMTimes: 10 Steps to Creating a Project Plan

Written by Elizabeth Larson on January 18, 2023. Posted in Articles.

Published: 05/17/2012

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.

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.

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.

The Courage to Try Something Old: Time Management – Part A

Written by Elizabeth Larson on October 12, 2022. Posted in Articles.

In the previous articles I wrote about the importance of the old skills of facilitating meetings and scribing and why it takes courage to use both. In this article I’ll give an overview another skill that has fallen out of favor over the years—time management.

We’ve been trying to manage time since the beginning of time and it’s not easy and it takes courage as you’ll see. [i] Whether our title is BA, PM, or vice president of sales, we have to manage our time. We need to manage our daily schedules and the projects or portion of projects that we are working on.

Here are some tips and tricks I’ve learned over the years that work when managing our daily schedules and our project work:

Not everything can be top priority. We can’t manage to an unspecific time period, such as tasks that are marked ASAP or “get this done before anything else you’re working on.” We can only manage to specific end dates.

End dates. When we have a small block of time available to us, it makes sense to complete a small task. But generally speaking we don’t want to complete small tasks before large tasks just because they’re easy. If we have a small task due in two week and a large task due in two days, we need to figure out how to get the large task done.

Less is more. In time management, smaller is better. We get large work done by developing the detail for what we know. We can estimate small user stories more accurately than epics for example.

Communication. When I started working on projects, I was under the false impression that I would always get every task done on time. And that I had to make a final commitment to a date before I had much detail, which made me and everyone around me miserable. Of course, we’re going to hit some targets and miss others. The key is to communicate as soon as we know we’re going to be late and set a new target at that time.

Resource availability. The key to every successful project is knowing how available each resource is. That is, we need to figure out how much time on average each resource spends on their non-project activities, including admin time, vacations, holidays, critical issues that arise and so forth. We also need to know how many projects people are working on. We have to mesh together those non project and project hours to get a realistic amount of time.[ii]

Here are some common time management pitfalls:

Being overly optimistic. Most of us think we and everyone else we work with have more time than we do. What I’ve learned over the years is that not only do tasks take longer, but we tend to estimate based on false assumptions. For example, we ask a stakeholder how much time they can devote to the project at hand They say 50%. So, we think, well that’s about 20 hours a week or four hours a day. However, I’ve learned the hard way that many stakeholders are lucky to have 4 hours a week to devote to all their projects—on average.

Estimating vs. reporting. A common pitfall is to start with the end date and then estimate how long it will take to get there. But we’ll be more successful if we first determine the deliverables then the tasks to complete the deliverables. Then we can we estimate how long each task will take. From there we can determine milestones and report end dates for each major milestone. In other words, estimate details but report at a summary level.[iii]

Estimating but not tracking. The best way to improve estimating both our project and day to day work is to track our time.

Managing our time is going to take courage because some people are going to view planning to the detailed level as intrusive. That’s particularly true when we ask them to track their time. We often get accused of micromanagement, a term thrown around to intimate us. They will say that But one of the easiest ways to lose credibility is to estimate poorly and keep revising our estimates. So it will take courage to counter their distrust.

What’s worked for me, over and over are three things:

Use detail to establish credibility. The first is to use the detailed estimates to keep people off our backs. If people say, how could it possibly take so long to get through business analysis for example, we can show them the detail and ask them what they would like to cut out and they never ask again.

Use detail to get more resources. These can be more team members, more stakeholders, and more technical staff, as well as more time and budget.

Use detail to improve estimates. Never ever under any circumstances use estimates to judge the performance of anyone in any way. If someone estimated a task would take 20 hours and it took 40 hours, we use it as a learning experience.

[i] I want to thank my colleague Barb Carkenord for reminding me how important this old skill is.

[ii] This is a huge topic and so important, that I will devote an entire article on it. And that article won’t be sufficient, because of the complexity of understanding and managing resource availability.

[iii] Agile methods, although labeled differently, use this method of estimating. So yes, I am a huge proponent of Agile

The Courage to Try Something Old – Part 1: Facilitation

Written by Elizabeth Larson on July 13, 2022. Posted in Articles.

We know that it often takes courage to try something new. But what about trying something old? Sometimes it takes courage to do the basics, things that we know work, but for a variety of reasons are deemed to take too long or seem too “old school.” Often the old ways are not welcome. To be sure, the old ways do not always add value. But when they do, it can take courage to convince the organization that it’s worth spending the time. The first one of these oldies but goodies that I will address is about facilitating requirements meetings. Even the concept of a meeting seems a bit old school, and when you add on the discipline needed to successfully facilitate, it can seem insurmountable.

The glorious thing about requirement meetings is that rather than interviewing many stakeholders separately, which is time-consuming, we can get the stakeholders together. It’s a chance to get issues discussed, questions answered, and direction set. But stakeholders may come unprepared or with hidden agendas. There are usually different personalities and communication styles which cause different types of disruption. And it takes courage to take the time to successfully facilitate. It takes courage to keep the meeting focused. Here are three tips that will provide you courage and increase the likelihood of success.

Preparation. No matter how experienced we are, no matter how many meetings we’ve facilitated, no matter how many disruptive stakeholders we’ve encountered, we face new challenges each time we facilitate a requirements session. We can’t eliminate the disruptions, but we can minimize their effect. Thoughtful preparation with the appropriate stakeholders will help us go into each requirements event with confidence. Minimally, we need enough preparation to communicate the following before the meeting:

• Objective. This is an action, stated as a verb. Examples include: to resolve issue(s), develop a process describing a current or future state, review the results of an iteration/phase, or project.
• Desired outcome. This is a thing, stated as a noun. Examples include: decisions, issues, parking lot topics, requirement models and lists, story maps, flows and other diagrams, user stories, action items, follow-up items, and responsibilities, to name a few.
• Attendees, prep work needed of each, and expectations for their contributions during the meeting.
• Topics to be covered, who owns the topic, and approximate time to be spent on each.
• Tools and techniques to be used and how, when, and by whom.

Meeting agreements (ground rules, protocols). The ability to keep focus during the session requires the use of meeting agreements, or ground rules. Throughout the years we have tried to soften the use of the term “ground rule,” maybe because “rule” seems so inflexible. Regardless, these agreements help keep us grounded. Getting participants to establish and then follow them, though, is tricky but necessary—necessary because disruptive participants can make everyone miserable. If we call out the disruptor, we risk breaking the safe environment and having the other participants shut down. If we do nothing, we will not successfully meet our objectives. There is no one right way to handle disruption. What has worked best for me is to anticipate disruption, include it in the prep work, and hold pre-meetings with those most likely to be disruptive. And the use of a parking lot can be one of the many agreements established.

Quick decision are not decisions. The final thought is that decisions cannot always be made during the meeting. There are a myriad of reasons why trying to curtail discussions and move forward will result in frustration and future changes. We can’t demand that decisions be during the meeting. But we can have a tentative agreement, and then it’s up to us to check in with reluctant participants as needed.
Sound a bit old school? Yes, of course. These are techniques that have been around a very long time. But they work.

We tried getting rid of meetings, and that didn’t work. We tried getting rid of meeting agreements. Chaos. We tried getting quick decisions, only to be blindsided and saddled with rework later. Sometimes the old is not the most popular, but it is the best approach, even if it takes courage to get people on board.

[i] I use the terms requirements meetings, sessions, events, and workshops synonymously.

[ii] I once suggested the use of a parking lot and some of the attendees didn’t know that it was a list of tangential topics that would be handled outside of the meeting or at a future one. They thought that we were actually going to meet in the company’s parking lot!

Critical Skills Needed for Project Success – Part 2 Translation

Written by Elizabeth Larson on December 7, 2021. Posted in Articles.

This article is part of a series and presents the second critical skill that all project managers (PMs) and business analysts (BAs) need for success. This one is about the importance of being able to translate technical complexity into business language. As the technology in organizations has become not only increasingly important to its success but also more complex, the need for business stakeholders to understand its true value has increased accordingly. Both PMs and BAs need to talk to their stakeholders about technology, its use, its value, and the results it produces. The language they use has to be about both the technology and the business and be stated in terminology that stakeholders understand.

BAs have always been translators. From the early days of business analysis to the present we have translated business requirements into specifications that could be designed, built, tested, and delivered. But translation has never ended there. We take technical designs and specifications and translate them back to the stakeholders to be sure they understand what they’re actually getting. We have been translators as technologies and methodologies have changed. So being a translator is nothing new. What’s new is that with more complex technologies like AI, the importance of translation is being recognized.

Years ago I started a new job as a PM. The team was full of technical jargon when they talked to me (OK) and in their discussions with stakeholders (not OK). I encouraged them to translate what they were saying into business language. So instead of talking, for example, about DB14 or problems with Joe’s program abends, I encouraged them to translate these issues into business language–to talk about Price information and how to fix the results caused by program errors. At first there was resistance, but gradually there was a focus on the business and not the technology. I’m not sure the team was entirely bought into a business focus. After all it’s cool to be able to talk techie. But I had several sponsors comment on the positive change.

The fact is, the more complex the technology, the greater the need for us to help stakeholders understand our elicitation questions so that they can make good business decisions and understand the ramifications of their decisions.

OK, so BAs have always been translators. What in it for PMs? We PMs spend lots of time with our sponsors and executives. I know how tempting it is to try to impress them with our technical prowess. We can easily fall into the trap of thinking we’re adding to our credibility by showing how fluent we are in the technical language. But far more impressive is understanding the technical terms and concepts well enough to clearly explain how the technology provides value to the organization.

To be successful translators, we need to understand not only the technology, but the business, including the industry, the organization’s goals and objectives, and the specific business area. But what does “understand” mean? On an AI project, for example, we don’t need to understand the details of model creation, but we do need to know that the algorithms being used further the business objectives. We need to be conversant enough in the technology to formulate our questions as well as answer questions that arise.

3 techniques for effective translation

Visual business models are among the best tools for the translator. Process, data, use case, and prototype models help the technical staff better understand the business requirements. Models abstract detailed information and present it in a way that’s useful to all audiences. Abstraction, of course, is the process of filtering out extraneous information, leaving only the essential details. Most people find models way more useful than requirements written in a lengthy list of “shalls,” which is how we used to document them.

When we translate, we also need confirmation from the business. Visual business models help translate back from the technical to the business stakeholders. The emphasis, of course, is on business models, because we don’t want to hand technical specifications or designs to our stakeholders without translations into business language.

Synthesis. Being able to translate means we need to take in a lot of information at once and almost instantaneously sort through it, discard the extraneous, and present the most important concepts. What helps us is understanding the context of the topic at hand. And we need both business and technical context. This allows us to take disparate facts gotten in previous conversations and put them back together in a framework that helps the business understand what we’re talking about and how they’re going to get value.

Elicitation. In Part 1 I covered elicitation, saying that we ask questions and listen to the responses, and that’s how we learn. There are times during translating when we need elicit information. For example, if we’re providing stakeholders information on AI results based on the algorithm used to create those results, we may want to ask the model creators why that algorithm was used or how it helps the business. Once we have this information, we can be confident that our explanation to the stakeholders is both technically accurate and valuable to the business.

Translation is critical to project success. It’s one of those skills that sounds easy, but which takes knowledge and a mastery of various skills. Translation is part of what distinguishes us from the order-taking BAs and PMs who are less valuable to our organizations.

Author: Elizabeth Larson