Portfoleon goes alpha

I am super excited, as we have reached the Alpha milestone with Portfoleon, so I am going to make a short post about why did I start making Portfoleon in the first place.

There are quite some great project management tools on the market already, such as Jira (my favorite!) or Asana or Wrike or TFS – and many more; the list goes on and on! It goes without question that you should have a tool to manage your projects 🙂

And yet with all this diversity I could not find any tool that could help me with my portfolio management needs, which happen to be quite different from what I need for project management. When I was looking for a tool, I took time to summarize my needs, and here is the first list I came up with.

I would like to continuously communicate my portfolio roadmap and priorities to the rest of the organization. I communicate differently to different stakeholders, so I need to be able to present the same information in the form of slides, documents, or email updates.

It is important that all the stakeholders can refer to a single source of truth about the current state of the portfolio, to minimize any misunderstandings of what is happening when and why.

From this single source of truth, different stakeholders can be interested in different slices of the portfolio. For example, resource managers will be interested in the workload for their teams, while the marketing department will need to know if we are going to make the release before the next AAOS event (I am working on medical software products and AAOS events are super-important for us).

The reality is changing fast, new opportunities appear, some things get postponed, and the other things get rushed, which is why it is very important that I can quickly and easily change the portfolio plans, without having to deal with a lot of constraints imposed by the system each time I need to shift a project for a week. Ideally, it should be easy as ‘drag-drop-publish’ 🙂

While I am working on changes to the plans, my stakeholders should still consult the latest approved version of the portfolio plan. When the new portfolio plans are ready, I will need to roll out the changes as a batch, so that the whole picture remains consistent.

Other managers should be able to work on other changes at the same time – without us having to take turns in checking-out / checking-in the whole portfolio plan.

When I am working on yearly and half-yearly budgets, I need to plan my resources and while doing so explore different what-if scenarios to see what options I can have in terms of budget vs. delivery.

I need to be able to monitor the portfolio health by checking portfolio metrics and KPIs, so that I could take action when needed.

To address all those needs, we are making Porfoleon and we are going to have the first closed beta soon! So please click ‘Sign Up for Beta’ and leave your email if you would like to participate!

In the next post, I will show how we are addressing all the needs above.

Cheers,
Anton

Do not make these mistakes when using Cost of Delay based prioritization

One of the most important decisions portfolio managers make is where the resources of the organization should be focused. There are tons of prioritization techniques to determine which project, epic, or feature should be the first to implement.

To make the best use of a prioritization method or technique, you should know how it works, what are its limitations and preconditions. In this post, I will show you three little “catches” of Cost of Delay (CoD) based prioritization methods, such as WSJF.

Understanding the role of Job Size

WSJF score formula includes job value and size, which may remind you of the ROI calculation. Compare:

and:

Both formulas include benefits (value) and costs (job size). However, the job size factor in the WSJF stands for an entirely different reason. The real intention of the score is to weigh the cost of delay against the lead time. Because the lead time is something that can vary depending on the situation (e.g., resource availability), the job size is the best substitute for lead time.

SJF will not indicate whether it makes sense to do the projects, and it will not replace your project selection process. The value of the score is in comparing it with the score of other jobs, rather than making any conclusions from its absolute value. This means you will have to pre-select the jobs using other methods before you apply WSJF prioritization.

Do not underestimate the time criticality factor

Many articles explain the cost of delay based prioritization using trivialized examples of calculating the cost of delay. While it will illustrate the principle, it is not enough to apply it in real life.

Typically, in such examples, you see how the cost of delay remains constant over time and prioritization becomes painfully easy. There are many situations where the cost of delay is close to a constant. For example, in a factory that produces 100,000 parts per week, a certain improvement project would lead to cost reduction of $1 per each part. Here, the cost of delay will be $100k / week.

If another project would lead to cost reduction of $0.8 per part, it would be obvious to figure out the priority between these two.

You will likely encounter more interesting situations than the constant CoD. Below are common examples.

Situation 1: Opportunity diminishes over time

Several competing high-technology companies A, B, and C are working on CPU chips for laptops. All three will release their next generation chips this year. Company B is planning to release in August, and Company C is releasing in November. You work for Company A, and depending on the project priority, you can release somewhere from May to December.

The cost of delay in this case may look like this:

Releasing in May will bring the most revenue because of more sales and more pricing power due to being the first to market. Revenue diminishes over time as competitors bring their products to market. With time, revenue decreases even further as the technology gets outdated, until there is no revenue to be made.

Likely, your function will not be as linear as shown on the graph. In the example above, the graph should react to the release dates of the competitors, creating valleys in the CoD.

Situation 2: Delay only matters after a certain moment

You are working on a large program to launch a space exploration mission to Jupiter. One project to prioritize is a project to design and manufacture a rocket engine. Suppose the mission is launching in 2022, and due to dependencies, the earliest time the engine will be used is 2020.

Here, the cost of delay before 2020 is zero, increasing after 2020, as delays to other projects are introduced.

As the delay is longer, more projects are affected, leading to further growth of the cost of delay.

Situation 3: One-time opportunity

Your organization has been shortlisted to be the catering provider for a large conference, which will take place in your city in five weeks. The project to prepare, organize, and provide the catering will only bring value if done on time. There is no value in launching the project earlier, as there is equally no value in launching it later.

The cost of delay may look like this:

Planning projects where the opportunity lifespan is short will require better project management –  particularly, risk management – to ensure delivery on time.

How to work with the time criticality factor in WSJF

Let’s see how we can deal with two projects – S1 (representing the Situation 1 above) and S3 (representing the Situation 3).

Suppose the lead time to execute S1 is 4 weeks and lead time to execute S3 is 2 weeks. Both projects will take all available resources and cannot be run parallel.

Cost of Delay for S1:

and like this for S3:

Alternative 1: S1 first, S3 second

Here, the “green rectangle” on the first graph will be captured, while the “orange rectangle” on the second graph will be lost.

Gained opportunity ~100, lost opportunity about ~2000.

Alternative 2: S3 first, S1 second

Here, we will deliver S3 on time, but will lose some of the diminishing opportunity on S1.

Gained opportunity ~2000, lost opportunity ~100.

Usually, you do not have to add the time criticality factor to the value and risk/opportunity score, despite what the formula says. Rather, you want to consider it when generating options. Depending on how complex your prioritization is, consider advanced tools, such as Monte Carlo simulation.

Do not underestimate the risk factor

Another component of the WSJF model is the risk reduction / opportunity enablement value factor.

Ignoring or underplaying the risk / opportunity factor can have a devastating impact on your portfolio.

Here are simple things you could do to quantify the risk:

  • If you are dealing with many risks of the same order of magnitude, you can use a simple EMV calculation.
  • If you are dealing with a large risk, you can assign it a cost of full insurance or implement an alternative to work around the risk.
  • For unacceptable risks, you can use an artificially defined value high enough to take priority.

Try, tune, try again

As with any other prioritization method, there are a lot of nuances in applying WSJF to your portfolio. Organizations have differences in culture towards risk tolerance, different situations with resources, different types of projects, and so on.

The method will require tuning when applied in your context. So, experiment to find what works best for you and your company.

Good Projects and Bad Projects to Have in Your Portfolio

Are projects the only reasonable way to develop products? Do you, as a portfolio manager, use projects as your only means to add value?

Projects “Cargo Cult”

According to the PwC global project management report, 97% of organizations believe that project management is critical to business performance and organizational success. However, the trust that organizations place in such projects backfires when managers, because projects worked for them in the past, start to automatically create projects for every possible change.

For example, an organization decides to create a commercial software product that would automate creation of expense notes for traveling employees:

The product manager (PdM): “I would like to create a project to deliver the first version of my product. The business case for my product has been approved by senior management.”

PMO: “We will appoint a project manager and start a project.”

The new project manager (PjM): “I am desperately trying to figure out the scope and constraints of this project, but there is just not enough data.”

The product manager (PdM): “Here are some features we would really like to have in the first version. We could have a feature to scan paper bills, optical text recognition to convert them into text, and perhaps an integration with some ERP plus a bunch of small features. Here’s the full list.”

The new project manager (PjM): “I will put these features in the scope statement. As we do not have any timeline, I will set an artificial deadline to keep the team “motivated” to deliver. Now, let’s kick off!”

Needless to say, this project will not deliver best value to the customers and, as a result, to the performing organization. In addition to poor business results, the teams will likely be demotivated, and the future of the product will not be the best.
(Hint: Never do such projects in real life!)

Instead of being a useful means to deliver value, such project management practices become a ‘cargo cult.’ Because projects are supposed to have a scope statement, budgets, and timelines, managers would start enthusiastically defining them – and, in case of absence of the real data about project scope and constraints, they would provide artificial or unverified data just to keep the projects ‘SMART.’ In reality, these projects are very far from being smart.

Alternatives for ‘Bad Projects’

Back to portfolio management. Contrary to popular belief, portfolios do not consist solely of projects. Project portfolio management defines a portfolio as a collection of projects, programs and operations, managed as a group to achieve strategic objectives.

It is up to you, as a portfolio manager, to decide what would be the best means to achieve the goals of your organization.

For example, in the situation above, you could start a team to work in a continuous delivery mode as software development operations. The team would deliver small increments, and continuously adjust the course based on user feedback.

(source: PMI standard for Portfolio management, 3rd edition)

Instead of a ‘bad’ software or IT project, you could choose DevOps to deliver value to your portfolio. In other cases, instead of running a large ‘bad’ project with a lot of interdependencies, consider starting a program to coordinate several individual smaller projects.

Not All Projects Are ‘Bad’

There are a lot of alarming statistics on the Internet about the failure rates of projects. Question: Does this mean that projects are to be avoided in your portfolio?

Further analysis of the statistics suggest that it does not. In high-performing organizations, a reassuring 89% of projects meet their objectives in contrast to low-performers, where only 36% of projects succeed. There is nothing ‘flawed’ in the concept of the projects, but you have to have the quality of the high-performers to successfully run projects.

In a high-performing portfolio, not only the projects are managed correctly, but also – and in my opinion more importantly – the right projects are managed. ‘Good’ projects have clear, SMART goals, reasonable constraints, adequate resources, and are aligned with the strategy of your organization.

One of the critical factors is the project size. Statistics suggest that small projects are eight times more successful than large projects!

For example, to make sure your EU customer data is properly protected, you would like your IT systems and business processes to comply with GDPR by 25th of May 2018.

You perform an audit of your systems and identify all the potential gaps you need to address. You make sure that legal, security, IT, software, and quality control teams, understand the challenge and have sufficient resources to move forward. You also have the full support of executive management. Your preliminary estimation shows that the total cost would be about 150-300kEUR.

In this case, starting a project could be the right choice to achieve compliance on time.

Conclusion, or When and When Not to Start a Project

Having ‘bad’ projects in your portfolio can lead to poor business results, low team morale, and sub-optimal product decisions.

Do not include such projects in your portfolio. Instead, consider other possibilities, such as creating a program and breaking the big project down into smaller projects. Sometimes, you will want to start operations to achieve the business objective instead of having a project or a sequence of projects.

Start a project when:

  • There is a clear mid or long-term goal to achieve
  • There are constraints to be met
  • Coordinated work of a (cross-functional) team is required
  • The size is reasonable to manage as one project

Do not start a project when:

  • The goal is not clear or a lot of change is expected.
    Consider an investigation project first, or continuous elaboration and delivery operations
  • There are no known time/cost constraints.
    Consider operations;
  • The effort is too large.
    Consider starting a program.

The Key to Good Project Kickoff

You know something is wrong when people on your project team come to meetings unprepared and waste time on endless discussions, find other things to do than what your project requires, and do not openly acknowledge there is a problem.

These symptoms indicate a problem that appeared as early as your project kickoff.

(source: clipartfest.com)

Here is how to do kickoff meetings that work.

Importance of the project kickoff meeting

The kickoff meeting is where all stakeholders involved in your project get on the same page, regarding the goals, roles and responsibilities, constraints, risks, and all other aspects of the project management plan.

It is necessary for project success that the stakeholders share the understanding of the project goals, know the plan, and have confidence in the project – and it starts with the kickoff.

If you do all the preparatory work right, the stakeholders will know a lot information you share on the kickoff meeting. Everybody should know why the project is done, the main factors that influence the project, and have at least some idea about the plan, because you actively involved the stakeholders in the preparation.

In the meeting, the stakeholders will meet each other, confirm their understanding of the goals, discuss their role in the project outcome, and interact with each other to clarify and strengthen their working relationship on the project. For example, the suppliers could align with the production on the detailed delivery schedule and the risk mitigation plan. Or, your team could ask about how you will communicate with the product manager if changes to the project requirements are needed. Such discussions will help to create lines of communication, flag important risks you might have overlooked, see new opportunities, resulting in more confidence and commitment.

All major stakeholders of your project should attend. The project manager, the project sponsor, the project customer, and the project team must be there. Depending on the situation, consider inviting other major stakeholders, such as the program and portfolio managers, functional managers, or senior management.

Conduct the kickoff meeting before the bulk of the work related to the project execution is started. However, usually, some project work would have been done already, for example prototyping work aimed to rule out major risks related to the technical feasibility.

(Source: slideshare.net)

Why kicking off too early may hurt your project

The timing of the kickoff meeting is important for it to have maximum positive effect on your project.

However, put the emphasis not on the timing, but on the content quality. Some managers believe that, until the project is kicked off, no work is done, and the resources are sitting idle and therefore push for the early kickoff at all costs. Such managers do a huge disservice to their projects with ill-prepared kickoffs done in haste.

At the kickoff, if you only bring a vague idea of what the project is about, but do not set realistic goals and the plan on how to get there, you will probably create no engagement or accountability from your stakeholders. People will leave the room with no clue of what they should do next. Were they merely informed about the project? Are there any expectations from them specifically? What are the next steps?

Later, when it is time to act, the stakeholders will debate about what the goals of the project are and who should do what; they will question every aspect of the project and the momentum to drive the project forward will just not be there.

Get a commitment

Your stakeholders should leave the room with a commitment to achieve the project goals and agree on the plan to do so.

To get the commitment of the stakeholders, you will need to work closely with them before the kickoff to define and sharpen the following:

  • Why the project is done. With your project sponsor, prepare the context and the business case. With the portfolio manager / PMO, align why this project was selected among others (see two simple questions to the portfolio management).
  • Project goals. With your project sponsor, define the goals. Usually, you will want your goals to be SMART.
  • Project constraints. With the sponsor, resource managers, PMO, and other stakeholders, define the time, budget, scope, quality, and other factors that constrain the project.
  • Plan how to plan. Define your approach to planning. You can use rolling-wave planning approach or plan the project scope upfront.
  • Scope of work and estimates. With the project team and other stakeholders, prepare the project scope and estimates for the time and cost. Create the baseline budget and schedule.
  • Major risks and opportunities that affect the project and what to do about them. Have a meeting with your stakeholders to identify the major risks and opportunities and decide how you will manage them. If you have a good risk management plan, your stakeholders will be more confident in the successful outcome.
  • Who is doing what. With your major stakeholders, define the roles and responsibilities on the project. You can use the RACI model.
  • Next steps. There are two major reasons you should clearly articulate the next steps. First, as beautifully shown in Cliff Giley’s article, it can sometimes take too much effort to agree on “the whole thing”, and you do not want to drown in small questions. Next steps will provide a good basis for everyone to start. Second, well-defined next steps create a dynamic feeling about the project kickoff and allow you and your team to jump into action immediately.

If you do your homework well before the project kickoff and conduct the meeting with the right people at the right time, you will get a lot more commitment and confidence in the project success.

Test your project portfolio management with these two simple questions

How do you know if project portfolio management is working well in your organization?

I mean – you probably have many procedures and tools you use to manage your projects, you fill templates to collect all the right data, and you rank your projects with sophisticated scorecards, but at the end of the day – does the entire system work and bring value?

While you can use different standards and carefully audit your portfolio management system, you can get a lot of good information just by asking a few good questions.

Check if you can answer, with confidence, the following:

  1. Why do we need to do this project now?
  2. How much value have we brought so far?

If this does not seem a lot to you, read on to see why these questions are so powerful.

1.   Why do we need to do this project now?

The answer may seem obvious – for example, you could say, “we are going to turn more profit if we make this project”.

However, this is not the complete answer to this question.

Yes, the project will bring us profit, but still, why do this project and another one? If you manage your project portfolio right, you have a system that allows you to select the best opportunity among all available and make the best use of your resources.

While your project may give a good return on investment, does it contribute to the strategy of the organization? Without strategic alignment of projects, the execution of the strategy of the organization will be impossible. In addition, the misaligned project is much more likely to fail or be canceled by senior management.

Before you can execute a project or even before that project makes it into the roadmap, it should be properly authorized. You should have a project authorization system, which will ensure the project has a slot in your roadmap and will receive necessary funding and resources. For example, in order to authorize a project to the portfolio, you may require a valid business case, or a technical feasibility study.

2.   How much value have we brought so far?

This question will address performance measurement, monitoring, and control of the portfolio execution.

First, the question implies that you are managing the value that your project portfolio brings to the organization. In contrast to project management, which is primarily concerned with producing specific deliverables, portfolio management is more about bringing value and achieving benefits.

The performance of a portfolio is primarily defined regarding delivered value against the investment; this is why the value of your portfolio should be measurable and quantifiable.

Finally, do you continuously monitor how your portfolio performs? Business value is only one factor among many others that you should be monitoring, but without a doubt one of the most important. You should also keep track on the expenditures, risk level, standards compliance, etc.

Start simple

Portfolio management can be very complex, but this does not mean you must implement all the possible requirements of portfolio management standards, especially right from the start.

You can add a lot of value by doing simple things, such as establishing the complete project list or making your project selection and prioritization process and criteria clear and transparent for the organization.