OnPoint, LLC

Looking beyond the project portfolio – aligning maintenance work

As we plan for implementing the organization’s strategic vision, our focus is on major programs and projects.  Which ones should be ended because they fail to support the new direction?  Which projects should receive additional resources?  How should we adjust our intake processes to ensure new projects are properly aligned?  The focus on new projects is appropriate and we should always look for better methods to ensure investments in new projects are carefully considered.  But let’s not stop there.  There is a world of work that exists outside of project portfolio management.

That work, sometimes referred to a maintenance or “run the business” includes maintenance and incremental improvements of installed systems, incremental improvements and keep-the-lights-on (KTLO) efforts.  In some organizations 80% of the work effort is on such activity and only 20%  is on major projects.  We should apply an appropriate level of scrutiny on this work to ensure it aligns with the strategic vision.

As with projects, this work needs business owners who will frequently prioritize a backlog of requests to ensure the effort is aligned with the strategic vision.  We need to provide the teams with training and tools to help them deliver results faster and with fewer delays, and we need to ensure the rest of the organization can make proper use of the results of these sustaining efforts.


Portfolio Management – Don’t lose your balance!

Below is a link to a Slide Share on my recent presentation at the 2016 Kansas City PMI Chapter PDD Days.




The Annual Budgeting Process – It Can Use Some Improvement

Over the years, I’ve had the opportunity to work with a wide range of managers and executives. Some had a very IT-centric education and background while others were decidedly non-technical. Most were command-and-control types while others viewed themselves as servant-leaders long before that description was popularized. The majority were calm and reasonable while blessedly few were screamers. If I were to assemble all of these people in a single location and ask their opinions they would not agree on much. Except for one thing – their dislike of the annual budgeting process. Since most 12-month budget cycles are started 3-4 months before the cycle begins, managers are asked to accurately predict what will happen in their organizations 14-16 months thereafter. They are asked to describe funding requirements for projects that have not yet been conceived and their performance will be judged by their adherence to a budget which is merely a wild guess. As organizations have attempted to apply agile principles at scale, managers have discovered that the annual budgeting process is not only disliked, it impedes organizational performance because:

      1. The extensive up-front effort to define and analyze project business cases yields little useful decision-making data and results in green-lighting projects with limited business value

        2. Project cost-overruns result in shifting funds from valuable early-stage projects in order to complete an over-budget project for which the business case is no longer valid

          3. It is difficult to reduce resources on approved projects to work on newly-identified opportunities with greater business value

So, how do we fix this dreadful process? Following are some sources of ideas for applying lean | agile principles to budgeting:

The Scaled Agile Framework (SAFe) proposes that, in lieu of project-based allocations, budgets should be based on funding long-standing teams organized around business value.

The Lean Startup book recommends Innovation Accounting for new products

The Lean Enterprise book advises the reader to eliminate project-based funding processes and separating funding decisions from the annual fiscal cycle

Means vs. Ends

I’ll start this post with a comment by Dr. Alan Weiss:
“The entire point of bureaucracy is the triumph of means over ends. The results don’t matter, only that the rules are strictly followed.”

Do those of us focused on lean | agile practices run the risk of setting up new bureaucracies to replace the old waterfall bureaucracies? Do we pay too much attention to the means (stand-ups, Kanban boards, story-points) and not enough attention to the ends (business results)? Do we focus so much on following rules that we lose sight of the external business environment, strategy and objectives? Do we understand the “definition of done” for implementing lean | agile practices?

I raise these questions because I am starting to experience déjà vu. Nearly two decades ago, a friend worked at a company that went all in for Six Sigma. The Six Sigma initiative took on a life of its own. Strong leaders were pulled out of line functions, became Master Black Belts and sponsored projects that were only loosely aligned with the business strategy. My friend, who was an English major, was required to learn Mini-Tab in order to retain his executive position. The change management program took hold and people at all levels began using acronyms such as DMAIC, DMADV, CTQ and VOC in normal conversation. Those who resisted change either left the company or their careers were derailed. The Six Sigma effort became bureaucratic and “enforcers” ensured that all the Six Sigma rules were followed to the letter. When viewed from a change management perspective, the transformation was successful. Unfortunately, the business failed and it was eventually sold to a competitor. The problem was not Six Sigma per se. The problem was that Six Sigma became the end.

As we embark on efforts to scale lean | agile principles and practices, we need to remind ourselves that we are seeking to improve business outcomes and the principles and practices are merely an effective means toward that end.

The Business Value of Speed

When we think of business value, we often think in terms of Return on Investment (ROI).  We may undertake a project with an eye toward reducing head count or otherwise leveraging the productivity of employees.  This view of business value has some inherent limitations.  The project costs often exceed the original budget, thus diminishing the ROI calculation. When the system is implemented, the anticipated headcount reductions are rarely taken.  Instead, the efforts of the employees are shifted to other activities which may or may not be more valuable.  More importantly, we are not increasing business value by more efficient work on products or services that our customers no longer want.

In today’s rapidly changing competitive landscape, speed can be far more valuable than squeezing the last ounce of productivity from administrative processes.  Consider the business value of launching a new software-based product six months earlier, responding to a customer question immediately rather than requiring a call back, or completing a customer project in a month instead of a year.

Should you adapt your metrics to focus on speed over mere efficiency?


Product Development – “Are we there yet?”

Those who sponsor software product development are frustrated by the time it takes to go from a great idea to the first trickle of revenue.  The months slowly pass and the sponsors adopt the refrain of children during a long road trip, asking “are we there yet?”  The product development team provides the parental response, “we’re almost there” and continues the usual product development practices.

The book, “The principles of Product Development Flow” by Donald G. Reinertsen, proposes that the sponsors are justified in their complaints that teams are taking a long and tortuous path to market.  Specifically, he points out that product developers focus too much on capacity utilization and not enough on cycle times.  As a result, the developers create large batches of work that result in large queues of work that are invisible to the product developer’s dashboards.

Reinertsen proposes a new flow-based product development framework, adapted from lean manufacturing, that seeks to measure and reduce the size of queues by reducing batch sizes and applying WIP limits. He proposes a prioritization method that takes into account cost of delay and the size of the job being scheduled.  Underlying this framework are some 175 principles that complement those of agile software development.  The book is quite deep and may require a couple of re-reads before the concepts settle in fully.

Per Reinertsen, this framework results in product development process improvements of 5 – 10 times, thus allowing product development teams to honestly tell their sponsors that, “we’re almost there.”

On time and on budget, but did the business benefit?

The project finished on time and on budget, therefore it was a success. From a project management perspective, it would appear that this is a true statement. As project managers, we are obsessed with reaching milestones. We monitor our project burn rates with greater scrutiny than our personal bank accounts. To a project manager, schedule slippage and cost overruns are signs of poor planning or sloppy management. On the other hand, it may be a sign that the project manager is thinking like a business owner.

When faced with a decision to delay a project implementation until quality concerns can be addressed, a business owner would consider the longer term impacts. A year from now, what would be the impact of a delay? What would be the impact of a flawed implementation? The proper business decision might be a brief delay.

Some projects, particularly new product launches, are inherently risky. Success criteria may not be clearly understood and the initial project approach might require a few corrections. From a project manager’s point of view, it would be preferable to undertake a thorough project planning process until all planning premises are clear and the budget estimates are solid. From a business owner’s point of view, the business benefit of being first to market might outweigh the risk of cost overruns.

The discipline of sticking to deadlines and budgets is critical to effective project management and, in most cases, the business benefits from such discipline. However, when there is a conflict between project management discipline and business benefit, the project manager must think like a business owner and promote the best interest of the business.

A Perspective on Stress

Many years ago, I was speaking with a relative who had just taken a management position at the Pentagon. Paul had been a bench scientist for decades, and was completely unprepared for the stress. Congressional staffers were demanding information, budget cuts were a constant threat, yet he noticed that a co-worker came to work every day whistling and in good spirits. He asked the co-worker, who was a retired colonel, how he was able to handle the stress. The colonel replied, “Easy – no one is getting shot here. What are they going to do to me? Yell at me? Call me names? Fire me? I’m okay with that. Last I checked, they aren’t taking us out in the parking lot and shooting us!”

The old colonel’s words are worth remembering.

Values – Aspiration vs. Reality

The Values section of business plans commonly mention customer focus and respect for others.  Unfortunately, it is a bit less common to see these values at work in the organizations.  Why is there such a difference between the plan and reality?  All too often, the values statements in the business plan are not consulted when making day-to-day staffing decisions.  Who is promoted, who is hired, and who is terminated?  The result of these decisions is commonly a management team that falls considerably short of the aspirations stated in the business plan.

Reflect on the attitudes and aptitudes of the key members of your management team, and consider the following:

  • Are they noted for their technical expertise rather than their understanding of the business or customers?
  • Do they employ distrustful or contemptuous language when describing their interactions with customers or colleagues?
  • Do they complain when customers change plans or priorities?
  • Do they excessively control the flow of information between their team members and the customer?
  • Would you characterize their personality as fault-finding rather than problem- solving?
  • Are they verbally abusive to those who report to them?

Decisions made in promoting people to leadership positions should be consistent with the strategic plans.  Otherwise, the entire organization will conclude that the plans are “merely words” and not to be taken seriously.

OnPoint, LLC