Shift-left is an Agile/DevOps call to action. It signaled the need to address quality sooner. As we adapt to the current dynamics, we should challenge standard paradigms and reevaluate when to execute project processes.
Timing is crucial for successful project outcomes. By shifting events earlier (left), later (right), or consistently doing others throughout the project (middle), outcomes can be improved. The benefits are more informed decisions, greater consistency, reduced costs, and better outcomes.
Shift Left
Shift-left activities that should be executed as early as reasonable. This increases clarity, reduces the cost of rework, and improves the likelihood of success.
Assign the Project Manager
Assign the project manager as early as possible- the sooner, the better. For large and complex projects, engage them during the pre-initiation stage when the business case is being developed.
Skilled project managers possess process and domain expertise that can inform and guide the project's direction. They understand the operational environment, technical boundaries, and stakeholders.
Critical assumptions and decisions set the project context during these formative stages, influencing planning and execution. Without knowing the backstory, the project manager is operating at a disadvantage.
I have been assigned “pre-packaged” projects more than once. The parameters were set, and I was told all I needed to do was execute. Soon after starting the project, things started to fall apart. It was then that I discovered fundamental assumptions and decisions that were not documented, which ultimately led to the project's failure. Had I been engaged sooner, I could have influenced the decisions or been aware of the pending pitfalls.
Project Objectives
Clearly describing the problem statement and project objectives is one of the first critical initiation steps. These definitional activities are often rushed or ignored. The results are disastrous. Effort is expended, but toward the wrong outcome.
It is easy to fall into the execution trap. Recently, I started getting “Low Memory” warnings on my computer. I jumped to the solution of buying a new one. Before making the purchase, I reframed the problem and clarified the objectives. The revised goal was better performance, which was easily achieved through a configuration change.
I have seen large organizations make similar and much costlier mistakes. The declared objective is a new system without clarifying the problem or the desired outcome. The system is deployed, but the old problems persist.
As the famed inventor Charles Kettering said, “A problem well stated is half-solved.” The first step is clearly understanding the desired outcome or objective. Otherwise, we are destined to be disappointed with the solution.
Success Factors and Acceptance Criteria
After defining the problem space, we should define the solution space. Success factors and acceptance criteria describe the desired outcomes.
Success factors are high-level—preferably quantifiable—expectations describing the intended outcome. Well-defined, clear, and measurable goals are key to project success. Acceptance criteria are more detailed and describe the intended solution. The project team knows the expectations rather than having to make assumptions or guess.
“Start with the end in mind,” as Stephen Covey said. When the outcome is known, we are more likely to achieve success. The solution can be built on clear expectations, avoiding downstream pitfalls such as unclear, changing, or unnecessary requirements and delivered features.
Definition of Done
Acceptance criteria are specific to a feature or requirement. The definition of done establishes overall quality standards for each step in the development process. This allows the team to “build quality in” and reduces costly rework.
Construction projects have well-defined regulations and standards. Technology and other knowledge-work projects do not have similar industry benchmarks. Defining internal project standards will improve quality, reduce frustration, and lead to better outcomes.
Shift Right
Shift-right activities may be done later in the project. Deferring this work honors the Lean principle of “deciding as late as possible” or “at the last responsible moment.” Waiting improves the decision-making process because better information is available. It also avoids unnecessary delays.
Design Decisions
Not all design decisions need to be made at the beginning of the project. Knowing everything may be expensive, the technology landscape may be evolving, or there may be information lags that cannot be averted.
We can apply emergent design principles to nearly all projects—the design emerges as more information is revealed as the project progresses. The concept is at the core of Agile software development. A colleague managed a 10-year effort to upgrade the technology at hundreds of embassies worldwide. Considering design decisions for facilities at the end of the list would have been wasteful—who can imagine that landscape?
Construction projects apply similar principles. Many detailed design decisions are made after work begins. Electric utilities are notoriously late in providing specifications for connecting commercial buildings to the grid. Construction begins, and requirements are incorporated when they are available.
Feature Decisions
Stakeholders often insist that all possible features be delivered with the initial release. They are afraid “if they do not ask for it now, they will never get it.” However, only a third of the features [1] in commercial software are regularly used. It is better to understand needs through experience than trying to anticipate all of them.
Every application is launched with an enhancement list. We should apply the principles of incremental and iterative delivery to shift feature decisions to the right. Build the “steel thread” from left to right when planning, designing, and coding an application. The steel thread represents the most simplistic or “happy path.” New features, functions, and levels of complexity can be added later.
Keep Middle
Keep in the middle are things that need to be done throughout the projects. These practices maintain execution discipline.
Stakeholder Engagement
Stakeholder engagement is the key to project success. A shortcoming of the waterfall approach is that stakeholders are primarily engaged at the beginning and end. Agile tries to correct this through regular and frequent.
Good stakeholder engagement includes:
· Periodically updating stakeholders on issues that concern them;
· Regular reviews, demonstrations, or walkthroughs of work in process; and
· Surveying stakeholders and the business environment to identify changes that may impact the project.
Risk Management
Risk management is the process of addressing uncertainty. Risks are future events representing opportunities (good) and threats (bad). They must be actively managed to capitalize on opportunities and mitigate potential losses.
Throughout the project, the project team should:
· Actively identify and document opportunities and threats in a risk register;
· Develop appropriately detailed and context-specific response strategies;
· Identify events or dates that would trigger the implementation of the response strategy and
· Periodically review and update the risks and the response strategies.
Continuous Improvement
Leading organizations practice continuous improvement. Project teams regularly reflect on how they work and identify and implement better ways of working. This is consistent with the practices of Kaizen and Covey’s Principle 7, “Sharpen the saw.”
© 2024, Alan Zucker; Project Management Essentials, LLC
See related articles:
· Create a Learning Environment: Profit from Your Mistakes [2]
· Peering into the Crystal Ball: 7 Tips for Successful Project Risk Management [3]
· Stakeholder Management: A Key to Project Success [4]
· Unlock the Power of the Project Management Plan [5]
To learn more about our training and consulting services or subscribe to our newsletter, visit our website: http://www.pmessentials.us/ [6].