Skip to main content

Tag: Planning

Putting Your Money Where Your Mouth Is

10 reasons I can think of that a company might try to avoid giving a raise/promotion:

  1. Budget constraints: The company may not have the financial resources to offer a raise.
  2. Performance issues: The employee’s performance may not meet the company’s standards.
  3. Market rates: The company may believe that the employee’s compensation is already in line with market rates.
  4. Company policy: The company may have strict policies about when raises can be given or how much they can be.
  5. Lack of value perceived: The company may not see the value in offering a raise to the employee.
  6. Poor communication: The company may not communicate clearly with employees about what it takes to earn a raise or how the process works.
  7. Fear of setting a precedent: The company may worry that giving a raise to one employee will set a precedent for others to ask for raises as well.
  8. Limited growth opportunities: The company may not have a clear path for career growth or upward mobility, making it harder to offer raises as an incentive.
  9. Profitability concerns: The company may be focused on maintaining profits and may be hesitant to allocate resources towards raises, even if employees deserve them.
  10. Internal politics: A jealous manager or supervisor may feel threatened by an employee’s potential and may try to block a promotion to avoid losing their own position.

 

Did you know that 75% of employees who leave their jobs cite lack of recognition as the reason? Or that a striking 82% of employees feel that they don’t get recognized for their work?! To be honest it doesn’t really surprise me… Effective leaders play a vital role in the success of any organization. They understand the importance of creating a positive work environment, fostering employee engagement, and promoting professional growth. By investing in their employees’ development, they show that they value their contributions and are committed to their continued success. Promotions and raises based on performance and capabilities are tangible ways for leaders to recognize and show their employees that they are valued.

The problem is many leaders think they are recognizing their employees through providing professional development opportunities and sending “thank you” emails. Professional development and recognition are not interchangeable. While training programs and skill development opportunities are important, promotions and raises are essential for employees to feel that their hard work and loyalty are recognized and appreciated. Of course, it is not the only thing that matters, but it seems to be underappreciated in many cases! If employees can see a clear path to advancement and recognize that their hard work and dedication will be rewarded, it can create a sense of purpose and commitment to the organization.

 

I once had a manager who told me that in my current position I was performing at the highest levels and that based on the projects I had taken on recently, it was justified to get a promotion. However, she went on to explain, she didn’t feel it was appropriate or reasonable to ask for a promotion within the first 1.5-2 years. While I respected her perspective, I also felt frustrated that my hard work and dedication weren’t recognized beyond verbal praise. When I asked for the promotion, she shouldn’t have stood on principle but instead she could’ve used it as an opportunity to build a loyal employee. If she had beat me to the punch, no doubt that would be even better.

Promotions and raises based on performance and capabilities are vital for employees to feel that their hard work and loyalty are recognized and appreciated. A promotion or raise is not just a financial reward; it is a visible sign that the company is investing in its employees and sees potential in their continued growth. This recognition motivates employees to work even harder and foster a culture of excellence and not to be understated, loyalty.

 

Advertisement
[widget id=”custom_html-68″]

 

The traditional mindset of basing promotions and raises on tenure is no longer valid in today’s fast-paced work environment. Employees today have access to a vast amount of information about comparable jobs and salaries. They can easily research and compare their current pay and benefits to what they could receive elsewhere. This comparison can either be a disadvantage or an advantage for an organization. If an employee sees that they could be making more money and receiving better benefits elsewhere, it may lead to disengagement, and eventually, the employee leaving the company. On the other hand, if an employee sees that they are being compensated fairly and could have worse benefits elsewhere, it can increase their engagement and loyalty to the organization.

Professional development and promotions go hand in hand. It’s crucial to provide employees with skill development opportunities, but it’s equally important to promote and encourage growth and hard work. Employees who excel in their current roles should be given the opportunity to advance their careers. Doing so fosters a sense of loyalty and commitment to the organization and ensures that employees remain engaged and invested in their work.

Despite the best intentions of many leaders, there can be barriers to implementing recognition and reward programs. Some leaders may lack the authority to make these decisions, while others may lack the resources to provide meaningful recognition and rewards. While some leaders may feel powerless in their positions to effect change, it’s important to fight for recognition and professional development opportunities for employees. Every effort counts and can contribute to a more positive and productive workplace culture.

 

How many of those 10 reasons a company might try to avoid giving a raise still seem reasonable?

In the end, we are all leaders in some way or another. We all have the power to influence those around us and create positive change. Whether we work alongside someone who deserves recognition, or we have the ability to make changes in our management philosophy, we should all strive to invest in the people around us. If you’ve felt a sense of agreement or even frustration while reading this, then you already have the permission to take action. Start small by advocating for a colleague or an employee’s promotion or raise, let’s see where it takes you…

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.