Skip to main content

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.

Why I Value Frameworks Over Methodologies

Early in my career, the head of IT gathered us together to introduce us to a new concept—a methodology. He pitched it something like this: “We’re going to start using new processes to complete our projects in IT.”

We’ll follow this set of rules that will take us from the beginning of the project to the end.” We didn’t think that would be particularly beneficial and we were pretty vocal about how this would slow our work down. So, after a few minutes of our grumbling, he tried again: “Wouldn’t be great if we could get Harvey to leave us all alone and let us get our work done?!” That we liked because Harvey was our collective nemesis—our main client who pressured all the programmers whenever he liked with constantly changing ideas. These never-ending changes caused a chaotic environment. We found it hard to get work done on time resulting in many complaints about us throughout the organization. The new methodology was introduced, and it did indeed improve our chaotic environment.

It did not, though, help our standing in the company. It was too inflexible and the clients like Harvey hated it.

That was the first of many methodologies that were introduced to our industry over the years. Some were quite technical, and others less so. Each purported to get projects done more quickly with more client satisfaction. Each touted that it was the latest and greatest and would solve all of IT’s problems. Each advanced the idea that if it were followed, the whole organization would be eternally grateful. Each started with good intentions, but each got bogged down in its own bureaucracy.

 

Is Agile a methodology?

Before I became a Certified Scrum Master in 2010, I attended my first presentation on Agile. The speaker reviewed the Agile Manifesto and principles and I said to myself—here’s something that takes good, solid project principles and puts them together in a practical way. At that time and to my delight, Scrum was called a “set of practices” which made a great deal of sense to me. Of course face-to-face communication is preferred, if not always practical. Of course we don’t want to get bogged down in needless documentation just to follow some mandated process.

Gradually, though, the word “methodology” replaced the phrase “set of practices.” And to some teams, calling a set of best practices a methodology gets misinterpreted as an unalterable way projects are completed. I remember attending a presentation where the speaker proudly discussed how documentation had been banned in her organization. “ And in another presentation a panel discussed whether virtual communication was considered face-to-face and therefore “allowed.” Agile was in jeopardy of losing its practicality and becoming bureaucratic. But Agile still works today when used as intended. It works, though, more as a framework than a methodology.

Advertisement
[widget id=”custom_html-68″]

 

So what’s the difference?

I think there is and has always been confusion between the two. According to the Scrum Alliance website, “Agile methodologies are the conventions that a team chooses to follow in a way that follows Agile values and principles.”[i] The use of the word “conventions” implies some flexibility. So what’s a convention? It’s a norm, an agreement for how in this case a team behaves and does things. I understand behavioral conventions. It makes sense to me that each team will create its own communication and behavioral norms and guidelines. My concern is that these methodology-conventions run the risk of becoming rules for every project—rules that don’t allow for individual problem-solving.

Frameworks by their nature are flexible. They allow teams to decide which practices make sense for their projects and which do not. A best practice may work well on one type of project or in one industry or organization but not others. Another best practice may work well for one set of clients, but not for others or with one team’s skillset but not another. Frameworks allow for these differences and usually encourage teams to choose among the myriad best practices described in the framework.

Sure, frameworks usually describe more practices than can be absorbed for any given project. That’s why it’s important for teams to understand what’s contained in the framework and choose the practices that work for them. If the team views the framework as an inflexible methodology, each step of which must be done on all projects, they may become overwhelmed and abandon it entirely.

 

I value frameworks over methodologies. Not that there shouldn’t be methodologies. It’s just that in my experience, frameworks are more flexible. They allow for individuals and teams to understand the context of their specific environments and make better-informed decisions. Frameworks provide guidance without demanding that each step be followed. Methodologies tend to become rigid over time. They are often used as a crutch when teams are unable to understand context and synthesize information. Having frameworks is important. It seems to me, however, that having bureaucratic methodologies can be self-defeating.

[i] [i] https://www.agilealliance.org/agile101/. They base this definition on Alistair Cockburn’s who suggested that “a methodology is the set of conventions that a team agrees to follow.”

The Courage to Try Something Old – Use Cases

There are many articles about project management trends for 2023. Among the common threads are a focus on AI and more automated PM tools. There are also contradictory trends like workers returning to the office or continuing to work from home. What I find most interesting, though, is that many of the trends have been around for years—like change management, agile and hybrid development methods, and focusing on benefits.[i] Does that mean that these old horses are not really trends? Not at all. It means that even when these techniques are out of favor, they are needed to successfully manage our projects.

 

One “old” trend I was happy to see was entitled Use Cases Are Back.[ii] Not that they’ve ever gone away. They’ve had different formats and names, like the Given, When, Then format, but the thought processes needed to develop a use case model have always been required.

To review, a use case is a model that describes how stakeholders want to use pretty much anything that’s being built, like a car, an elevator, a phone app, or a change to an existing system. But defining them is not easy. We can’t just ask our stakeholders how they would like to use a microwave or what functionality is needed in a sales app. We need to ask the right questions. And a use case model is a great tool for getting at those requirements.

A use case model, like almost all models, has both a graphical and textual component.[iii] The first component, a use case diagram, is a picture of the how the stakeholders will interact with what’s being developed. It identifies all stakeholder groups who will use the end product and how they want to use it. It also describes all the systems and other components needed to make it work. It becomes a picture of all the people and technical components, as well as all the functionality needed to make it useable. And it’s a great picture of the scope of the effort.

 

Some PMs and BAs have trouble getting started, so I have developed 5 business questions that can provide a jumpstart in the creation of a use case diagram.

Use Case Diagram Questions

  1. What’s being built? It’s usually called a system, but we can call it whatever we want. Examples include a new car, a change to an order system, and kitchen cabinets.
  2. Who are the stakeholders who will use this system? These are often called actors, such as an auto service consultant, a consumer, and cabinet designer.
  3. How do these stakeholders want to use the system? What functionality do they need? These are the use cases themselves. They are stated as high-level processes, like Start Car, Order Product, Measure Cabinets.
  4. What other systems or components will interact directly with the system? These are also commonly called actors, like Ignition system, Replenishment system, and Cabinet Delivery Schedule system.
  5. How will the actors and the system talk to each other? These eventually become the user interfaces that allow the system to recognize what the actor wants to do. The driver sends some signal to the Start Car use case. A consumer enters an item into Order Product use case. A cabinet designer enters measurements into a design cabinet use case.

The textual component is known as a use case narrative or scenario. It describes the process steps which detail the interaction between the stakeholders and what’s being built.

 

Advertisement
[widget id=”custom_html-68″]

 

For example, how do we start the car? Does the driver put a key into the ignition? Press a button? Does the car start when the car phone app is connected and the driver opens the door? Something else? There is no one right answer. But the questions below will help our stakeholders go through the required thought processes.

Use Case Scenario Questions:

  1. How do I know where to begin? Preconditions provide the answer. They tell us where to begin by describing what has already occurred. In our example, do I already have my keys? Have I already unlocked the car? Adjusted the mirrors? More preconditions mean that the use case scenario will be shorter and there will be fewer different paths. For example, if a precondition is that I have my keys, we don’t need to document what happens when I’ve lost my keys in this scenario.
  2. How do I know when I’m done? These are the postconditions. We stop when we reach these conditions. The pre and post conditions form the scope of the use case because they define what’s in and out of each one.
  3. What is the most common way of getting from the pre to the post condition? This is the “happy path.” There are no decisions in this path, such as what happens if the car won’t start.
  4. What are other ways of getting from the pre to the postcondition? These are the alternate paths. The car starts, but it takes three tries.
  5. What prevents us from getting to the postcondition? These are the exception paths, like when the battery is dead.

Use case models are extremely useful for getting the requirements of the interaction between stakeholders and what’s being built. There are other ways of getting them, but the structure of the use case can help us focus on what questions to ask and ultimately saves time and frustration.


[i] https://www.theprojectgroup.com/blog/en/project-management-trends/; https://www.replicon.com/blog/project-management-trends/ are two examples.
[ii] https://www.projecttimes.com/articles/top-business-trends-to-watch-for-in-2023/
[iii] I’m not including a use case diagram because of the many different conventions used. What’s important are the thought processes, not the conventions.

The Fallacy of SMART Goals

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.

 

Advertisement
[widget id=”custom_html-68″]

 

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

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?

 

Advertisement
[widget id=”custom_html-68″]

 

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.

  1. Identify activities and tasks needed to produce each of the work packages, creating a WBS of tasks.
  2. Identify resources for each task, if known.
  3. Estimate how long it will take to complete each task.
  4. Estimate cost of each task, using an average hourly rate for each resource.
  5. Consider resource constraints, or how much time each resource can realistically devoted to this project.
  6. Determine which tasks are dependent on other tasks, and develop critical path.
  7. 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.
  8. 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 – 4th edition.

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

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]

 

Advertisement
[widget id=”custom_html-68″]

 

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