Skip to main content

Tag: Planning

Integrating User Stories in Project Planning & Deliverable Development

An important part of managing any project is being able to break the project down into its component parts.  A good project manager and project team need to know and fully understand what a project is intended to do in order to plan and develop the details of the project deliverables.

Project deliverables, according to the PMBOK Guide, are, “Any unique and verifiable product, result, or capability to perform a service that is required to be produced to complete a process, phase, or project.”  (Project Management Institute, 2021).  Simply put, deliverables are what a project creates or produces – the output of a project.  Those deliverables can be tangible, such as physical objects like products, or intangible, such as events or processes.  They define what a project should make or do.  When deliverables are correctly defined, each deliverable should come in two pieces.  One piece is the deliverable itself and another piece is the associated success criteria for that deliverable.  Success criteria can be broadly explained as the criteria used to measure project success (Castro et al., 2019).  Success criteria come in a broad range of formats, with elements and standards able to be applied to different projects as appropriate.  If a project deliverable is successfully completed, success criteria spell out in detail what that success should look like.

There are a number of different practices for addressing this part of project planning.  From informal discussion and consideration to structured, formal brainstorming sessions.  User Stories are one tool that every project manager should have in their toolbox for creating and defining project deliverables.

 

User Stories

A user story is a short statement in the everyday language or business language of the end user of a project’s output that captures, summarizes, and articulates what a user does or needs to do with that output.  It states what the user of the project output wants that project output to be able to do or what they want to be able to do with it.  User stories describe the features of a projects output from the point of view of an end user.

User stories have their background in agile practices in software development.  In this context, user stories are written to describe the features to be included in a software or technology project.  Assembled together, the list of user stories makes up the product backlog, or list of features to be built into and included in the project.  Based on order of priority, those features are pulled from the product backlog for inclusion in a sprint cycle.

As agile practices have since expanded well beyond the software and general technology sector and into use in all types of projects, so have user stories.  They have since become a useful feature in describing the output and elements of various types of projects.

User stories are written in a standardized format.  They clearly define the end user in mind (the who), the feature to be described and included (the what), and how the user will use that feature of the product (the why).  The format for user stories is, “As a   (user role)  , I want a   (product feature)  ,  so that I can   (benefit / use description)   .

Who

The “Who” element describes the role of the user.  It asks and answers the question, “who will use the output and receive value from a particular output feature?”.

 

What

The “What” element describes the product feature itself.  This is the deliverable item of the aforementioned output.  In agile teams, this would describe one unit of delivery.  It is a single, individual feature of a projects output.

 

Why

The “Why” clearly describes how the user defined in the “who” part of the story intends to use the feature.  What will they do with the feature and how does it bring value to the output of the project?

Examples of user stories include:

  • As a listener, I need a tuning button, so I can find my favorite radio station.
  • As a theater visitor, I need a ticket, so I can attend the performance.
  • As a convention delegate, I need a schedule of events, so I can plan my day at the convention.

Several slight variations on the format exist, but the general point is always the same – identifying the user, describing the output feature, and detailing its use or function. The elements can be broken down and considered in those three parts.

 

Advertisement
[widget id=”custom_html-68″]

 

Story Cards – simplified approach

Story cards are the tools used to create, arrange, and organize user stories.  Each story card is a user story as a self-contained description of a project feature, with additional accompanying elements included along with it to help further define the details of that feature.  User stories are traditionally written on physical, individual cards in order to establish the details of each user story and to facilitate the reprioritization and rearrangement of the stories for inclusion in the project.  In contemporary practice, story cards can be created and arranged in digital form, using various project management, storyboarding, or digital whiteboard software and applications.  Any format works, as long as it can be viewed, shared, discussed, and changed by the project team members.

Just as user stories themselves have some slight variations in structure depending on the specific methodology followed, so do story cards.  At a basic level, a user story card should include a title, a value statement, basic requirements, size estimation, and acceptance criteria.

 

Title

The title of the story card is exactly what it sounds like.  It is a shortened or abbreviated name of the story.  It should be sufficiently expressive to describe the feature it defines.  Titles help to organize the stories for arrangement and prioritization.

 

Value Statement

The value statement is the heart of the story card, presenting the user story itself in the format previously set out.  It describes the user role, the feature to be included, and the benefit or use of that feature to the end user.

 

Basic Requirements

The basic requirements section is a flexible element of the story card and can be used to further define some of the essentials or expectations of the feature or its development.  This can include anything from aspects of functionality to resources or constraints in producing the feature.  The Basic Requirements element can be included or omitted at the discretion of the project manager or as the feature itself necessitates.

 

Size Estimation

In agile methodologies, the size estimation is typically done using an estimation point system.  In other practical usage, a time estimation is useful to include and sufficient to further define the story.  This is done by estimating, in time or work units, how long the feature will take to complete as described.

 

Acceptance Criteria

Acceptance criteria describe the basic benchmark that has to be met in order to consider the story complete.  It is a description of a successfully completed and functional feature.  Acceptance criteria can be written by asking and answering the question, “If this feature is successfully included, what does that success look like?”

 

Application

In agile methodologies such as Scrum, the collection of story cards makes up the Product Backlog, or list of features to be selected for inclusion and built into the project during an iterative sprint cycle.  For more traditional methodologies, user stories and story cards can serve a number of roles.  They can help to describe and define features of a projects output from an important point of view – that of the end user.  In project brainstorming sessions, this approach helps project team members to take on that role in considering features.  Once those features are defined, they can be added to the deliverables list for the project, either as final deliverables or for inclusion in an iterative development cycle.  Finally, they can be used to supplement a traditional Work Breakdown Structure.  In this way, the story cards can create additional WBS tasks and activities for inclusion in the project schedule.

 

Any way they are applied, user stories and story cards are a useful tool for project managers to have in project planning and development.  They provide a structured way to consider project features, activities, and stakeholder groups.

 

 

References

Castro, M., Bahli, B., Farias Filho, J., & Barcaui, A. (2019). A Contemporary Vision of Project Success Criteria. Brazilian Journal of Operations and Production Management, 16(1), 66-77. doi:10.14488/BJOPM.2019.v16.n1.a6
Kissflow Project. (2021, November 23). How to Identify and Manage Project Stakeholders? Kissflow Project. Retrieved May 31, 2022, from https://kissflow.com/project/project-stakeholder-management/
Project Management Institute. (2021, March 21). PMBOK Guide, 7th Edition.
San Cristóbal, J. F. (2018). An analysis of the mainproject organizational structures: Advantages, disadvantages, and factors affecting their selection. Procedia Computer Science, 138, 791-798.

Projects are Fragile… Yet Their Failure Is Not Always Indisputable

The flight from New York to London was without incident. The pilot avoided turbulence by requesting timely altitude changes, the flight attendants were attentive, and food and drinks were surprisingly pleasant. The landing, however, was a little rough and those last few seconds surely influenced some passengers’ opinion of this 7 ½ – hour flight. For some, it turned the entire flight into a bad experience or a “failure”… even though – and unbeknownst to the passengers – a rough landing was required for safety purposes given the strong crosswind upon arrival (the landing gear must make contact with the runway as soon as possible). For others, the flight was satisfactory after all.

There are many variables at play that will influence the outcome of a flight and stakeholders (here the passengers) will have their views on the quality of that outcome. The same can be said about projects, what drives them and their final output. What appears to be a failed or semi-failed project might actually contain some silver lining elements.

 

Projects are fragile

As shown in Table 1, many project risk variables (we count 23 of them) can impact the outcome of a project.

Those can be classified in 5 broad categories:

  1. People
  2. Tools
  3. Communication
  4. Planning
  5. Strategy

Since projects are driven by people, it is not surprising then that the People category is the largest with 9 out of 23 potential root causes of project failure with some occurring at the start of a project but most of them taking place mid-course of a project life cycle which makes it harder to mitigate them in a timely fashion.

A large number of mitigating factors will require pausing the project, otherwise this would be equated to the overused expression of “attempting to change a tire on a moving car’. Many of the proposed mitigants require the intervention of a third party (e.g. stakeholders, steering committee or management). This adds yet another set of challenges to the needed intervention.

 

Advertisement
[widget id=”custom_html-68″]

 

Another layer of complexity is introduced whenever project risk drivers are correlated or become part of a domino effect. Did the lack of resources cause the project to be delayed and then the cost overrun? Did the lack of sponsorship lead to the project manager becoming disengaged and project risks not flagged in a timely manner? Or did those variables manifest themselves independently?

In most cases these project risk elements will be correlated that is why it becomes critical to identify them as soon as possible in order to make the appropriate course correction to avoid a project failure.

Table 1 presents a list of project failure causes – from start to end of project – and proposes ways to mitigate them. The purpose of Table 1 is not to simply present a comprehensive list of mitigants (as variations of such mitigants can be implemented as well) but rather to suggest that what is critical is to identify the project risk variable and begin the process of curing it by a variety of approaches.

 

Table 1 – Project Failure Drivers

 

Project failure is not always what it appears to be

In light of such a long list of potential project failure points, it is natural to then take a closer look at project failure itself, or more precisely the various types of project failure that might ensue. These can be broadly classified by the nature of the impact to the project delivery, which can have objective characteristics (e.g. defective delivery or cost overrun) or more subjective ones (e.g. poorly communicated outcome even for a successful project).

As shown in Table 2, many apparent project failures can have their silver lining, especially when it comes to impact on ROI (Return on Investment). Indeed, what sometimes appears to be a categorical project failure, can actually hide some degree of silver lining.

Table 2 – Project Failure Types

Finally, it is worth noting, as depicted in Table 2, that even though a lessons learned exercise is a must at the conclusion of every project – especially those deemed to have “objectively” failed – the depth and intensity of such an exercise may vary by failure type as one considers other priorities calling upon an organization’s resources.

Goals are NOT Expectations: Change Mindsets to Avoid the Suffering of Disappointed Stakeholders

Goals are something to work toward or aspire to. Expectations are beliefs that something will occur in a certain way. Goals are not expectations. And knowing the difference can help to avoid unnecessary disappointment and conflict.

 

Last month I wrote about embracing imperfection to achieve ongoing performance improvement. The implication is that we must expect imperfection, though it is certainly not a goal. Over time imperfection (for example schedule overruns, defects, and unnecessary conflicts) is very highly probable. So, expecting it to occur is realistic. It is what risk management is all about.

We also expect to achieve our goals. That expectation may be more or less realistic, depending on the goal and the capacity of the people involved to achieve it.

 

The Problem and Symptoms

While it may be wise to have no expectations, they are a natural part of life. The expectation is not the problem. The problem is failing to remember that the expectation is a belief or desire subject to uncertainty and change.

Failing to remember is a problem because it leads to unnecessary stress in the form of anxiety, anger, blaming, and more. Symptoms are conflict, unmet objectives, and the disappointment and unease of unfulfilled expectations.

 

Case Example

Imagine this scenario. Senior stakeholders have set a goal. To accomplish it means initiating work in late March, to meet the need to use an expensive, elite contractor team, only available for three months. At the end of June, the resources are firmly committed elsewhere.

According the contractor’s detailed schedule and a guarantee, the work these resources will perform can be done in three months, with some time set aside as a buffer to account for delays related to the work itself, for example sick time, slippage, testing, etc. The contractor agreement stipulates that if work does not begin in March there will be no guarantee of completion by June. If the team has to leave without completing the work the entire project will be significantly delayed.

Project management and the steering group expect that in the two months beginning January 30th the negotiation of a contract and the receipt of permission to perform the work from a corporate controller will be completed so our elite team can begin their work on the planned March start date.

 

Advertisement
[widget id=”custom_html-68″]

 

Contract negotiations with the involvement of a legal department has commonly taken an unknowable amount of time owing to the availability of attorneys, their priorities, and the issues that come up in the negotiation. The time the controller department takes to review and sign off begins only after the contract is signed and is subject to committee schedules and the number and type of issues found.

Senior sponsors expect the PM to take care of everything and get the job done. The PM believes that the predecessor tasks will be done quickly, trusting in the attorneys and accountants to do their jobs on time.

What is the likelihood of slippage? When it happens will there be anger and blaming or acceptance and understanding? Who will pay the costs associated with the delays.

 

The Cause

Over confidently expecting goals to be met with certainty is the problem. But what is the cause?

The cause is ignoring the fact that expectations are beliefs and that there is uncertainty about them being met. People tend to ignore this reality because they are so attached to the expected outcome that they can’t bear the thought that it won’t be accomplished. we tend to like certainty, especially when it comes to accomplishing or acquiring what we want.

The root cause of suffering is ignorance which appears as attachment and aversion, according to Buddhist psychology. It seems true. We tend to cling to an impossible idea or belief until we are convinced it is impossible. For example, being certain that we will meet our schedule (“I’m sure the legal department will get back to us with time to spare”).

Ignorance is an interesting word. Many people are insulted by being informed that they are ignorant, they don’t like to admit they are ignorant of something. Others do not realize or care that they are ignorant of something, for example the demanding boss/client/sponsor/project manager who is not aware of the complexity of the work that has to be done and the risks involved, and who isn’t motivated to find out.

The good news is that since ignorance is not having knowledge or information, it is curable.

 

The Solution: Risk Management

There is a solution to the problem of over confident expectations. It is to cure ignorance by making it clear to every stakeholder that uncertainty must be accepted because uncertainty in project work is an undeniable reality. That is why risk management is part of the project management process.

The core of the solution is to change mindsets. The desired mindset is one that expects uncertainty and change.

Mindset change can occur as part of a formal training program. Or it can be in the form of content in conversations, proposals and plans that highlight where there is uncertainty, what the probability of negative and positive outcomes, and what impact they may have. Mindset change can be as simple as presenting ranges of cost and schedule expectations.

With a change in mindset, practice estimating and scheduling skills to integrate risks and buffers to assess multiple scenarios and get a practical sense of how likely it is under various conditions to achieve the goal. Then throughout project life report, reassess and adjust as needed to manage expectations.

 

Going Forward

Eliminating the pain triggered by mistaking goals for expectations is simple. Get rid of ignorance and the light goes on making everything better. Simple but not easy. changing mindsets takes intention, time, and skillful effort. It is a change management or transformation program.

The effort is easiest if there is an existing process improvement process and mindset is addressed as part of it. If that is not the case, then the effort is more difficult. If the most senior leadership is open-minded and aware of the situation, change is more likely to be successful.

If the cause is not recognized on the highest levels, then rely on subtle bottom up change in which there is firm push back and skillful communication to set rational expectations.

 

References:
Managing Expectations: A Mindful Approach to Achieving Success by George Pitagorsky
The Zen Approach to Project Management by George Pitagorsky

Maximizing Impact and Efficiency with Zero-Based Portfolio Prioritization

Introduction

In today’s competitive business environment, it’s important for organizations to stay ahead of the game. One key to success is being able to effectively prioritize and deliver on projects that will drive strategic goals and bring about competitive advantage. This is where zero-based portfolio prioritization comes in.

But first, let’s consider the importance of prioritization to your portfolio and your business.

 

Why Prioritize?

Effective project prioritization can bring a number of benefits to your organization, including:

Improved return on investment: Studies have shown that prioritized projects are more likely to drive greater ROI and overall value, as they are more closely aligned with the organization’s strategic goals. Additionally, projects that are well-aligned with strategy are 45% more likely to be delivered to budget and 50% more likely to be delivered on time.

Better support from senior management and other key stakeholders: When projects are clearly linked to strategic imperatives, they have a 57% higher likelihood of success. This is due in part to increased engagement from senior leadership and greater energy behind the projects, which can result in more resources being made available to deliver them.

 

Reduction of waste: Prioritization ensures that organizations are focused on projects that will add value, rather than those that are no longer relevant. All too often, organizations continue working on outdated projects that consume valuable resources that could be put to better use elsewhere.

Avoidance of resource overload: When organizations do not focus on the most important projects, resources can be stretched too thin, leading to bottlenecks and delays on critical projects. Prioritizing projects effectively frees up people to work on the things that really matter, which can also be more motivating for team members.

What is the Zero-based Portfolio Prioritization Process?

Zero-based portfolio prioritization is a method of evaluating and prioritizing projects based on their potential value, rather than their place in a pre-existing hierarchy or list of priorities. It involves starting with a blank slate and reviewing each project based on its current potential value to the organization.

There are a few different methods that can be used for zero-based portfolio prioritization, including weighted scoring, MoSCoW prioritization, the Eisenhower Matrix, and the Impact and Effort Matrix.

 

Advertisement
[widget id=”custom_html-68″]

 

Implementing Zero-based Portfolio Prioritization

So, how do you go about implementing zero-based portfolio prioritization in your organization? Here are the key steps to follow:

Define your criteria: To effectively evaluate and prioritize projects, you’ll need to decide on the criteria you will use. This could include things like ROI, risk level, resource requirements, and cost-benefit ratio. Involve key stakeholders in this process to ensure that the criteria align with the organization’s strategic goals and needs.

Review and evaluate projects: Once you have your criteria defined, review and evaluate each project based on how it aligns with the criteria. This could involve creating a matrix or other tool to help you score and compare projects. Be sure to consider both quantitative and qualitative benefits in your evaluation.

Communicate and act: Once you have your prioritized list of projects, it’s important to communicate the changes to all stakeholders and start working on the revised plan. This can be challenging, as some team members may be disappointed if their projects are deprioritized. Be sure to clearly communicate the reasons for the changes and how they align with the organization’s goals to help mitigate resistance.

Monitor and evaluate: Ongoing monitoring and evaluation of the prioritized projects is key to ensuring that they remain aligned with the organization’s goals and that resources are being used effectively. This may involve regularly reviewing and adjusting the criteria used to evaluate projects, as well as tracking progress and outcomes.

 

Challenges and Considerations

While zero-based portfolio prioritization can bring many benefits to an organization, it’s important to be aware of the potential challenges and considerations that may come up. These could include:

Resistance to change: As mentioned, it’s common for team members to resist changes to project priorities, especially if their own projects are deprioritized. It’s important to clearly communicate the reasons for the changes and how they align with the organization’s goals to help mitigate resistance.

Difficulty in evaluating and comparing projects: It can be challenging to accurately evaluate and compare projects, especially when some benefits are hard to quantify. It’s important to be thorough and use a consistent approach to ensure that projects are being compared fairly.

Ensuring alignment with strategic goals: It’s essential to ensure that the prioritized projects are aligned with the organization’s strategic goals. This may require regular review and adjustment of the criteria used to evaluate projects.

 

Limited resources: Even with effective prioritization, there may be times when the organization simply doesn’t have the resources to tackle all of the highest-priority projects. In these cases, it may be necessary to prioritize further or look for ways to free up resources.

Overall, zero-based portfolio prioritization can be a powerful tool for organizations looking to align their priorities with their strategic goals and ensure that resources are being used effectively. By carefully defining criteria, evaluating, and comparing projects, communicating and acting on the revised plan, and monitoring and evaluating progress, organizations can make the most of their resources and drive greater success.

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.