PM Articles > Geof Lory > Assessing Readiness for Speed - Execution Management

Assessing Readiness for Speed - Execution Management

by Geof Lory

Related Articles
  Product Management
  Speed Readiness Assessment
» Execution Management
  Project Management
Last month's article started a series on Assessing Readiness for Speed. By breaking down readiness into the essential disciplines and then proposing a set of items that can be reviewed and evaluated through empirical measurement, the assessment helps determine how well your project team is positioned for speed. Last month we started with the assessment of Product Management. This month we will expand on that topic and include the second set of disciplines -- Execution Management.

The Execution Management Disciplines

Product Management, you will recall, focuses on the questions Where, Why and What. In contrast, Execution Management concentrates on How, Who and How Much. The team starts by elaborating the Where to an actionable level, which creates a more tangible and testable What. Once that is done, execution can focus on the How. How are we going to get to where Product Management wants to go? Who will we need and How Much time and effort will it require to get there? This is where the rubber meets the road and the project gets traction, executing on Product Management's vision.

Execution Management aims to get the ideas of Product Management into a usable product as quickly as possible with the highest level of quality at the lowest cost. The disciplines of execution are all about throughput: more, faster, better, lower cost. The intentional juxtaposition of Product Management and Execution Management creates the crucible in which great teams are nurtured or wasted and world class products and services are developed or squandered.

Lessons in Execution from Lean Manufacturing

Many parallels can be drawn between manufacturing and software development, but most agilists shy away from the "software factory" concept implied by those comparisons. Unfortunately, in avoiding it, they throw the baby out with the bathwater. Most manufacturing execution practices can be highly regimented because they are guided by a known outcome. Software development has a higher degree of unknown outcomes, so agilists shun the limiting nature of these rigid procedures. However, many Software Engineering practices could benefit from more process, in the form of greater consistency and less unnecessary, reinvented or redundant work. Knowing when effort is augmented by process and when effort should be left to personal discipline is something that comes with experience.

One of the developers on our team refers to the Execution Team as the "engine room." I like this analogy. It makes me think of some of the applicable lean practices while allowing for situationally specific less rigid behaviors. Let's use the case of Scotty in the engine room on the starship Enterprise. Day in and day out, Scotty uses lean practices to maintain the engine room at peak performance. The right tools are available, organized, cleaned and readily available for use by his staff to maintain optimal performance. Nothing is ad hoc. So, when Captain Kirk calls for warp speed, Scotty delivers and Kirk sits comfortably in the captain's chair. Smooth sailing as expected. No one wonders how to make that happen, least of all Scotty.

Enter the Klingons. A blow to the bow and the engines can no longer perform as planned. The call comes down for warp speed and Scotty's response, "I'm doing all I can, Captain." At this point the adherence to procedures and rigor go out the window and the intuitive disciplines based on extensive experience kick in. By hook or crook and a lot of heroics, Scotty and his crew get it done, but, as the saying goes, "that is no way to run a starship." It is not sustainable. The reality is that the practical application of rigorous procedures based on disciplined training and experience establish the foundation for appropriate execution under duress. This experience creates tacit knowledge that guides execution and doesn't require external governance or rigid process to maintain. This is conscious discipline over managed process.

Balancing the Level of Discipline and Process

The real challenge is to know how much process to apply, and this only comes through practice and conscious assessment -- the learning loop. That is exactly the intent of the assessment questions in the Speed Readiness Assessment. They should stimulate the discussion around certain areas, but they are intentionally phrased in a way that won't imply too much prescription. Hopefully this leaves plenty of room for the nuances of the team and project while providing enough guidance for conscious evaluation and eventual improvement.

Different activities within Execution Management will span the continuum. When searching for the right level of discipline versus process, try the following approach. Instead of immediately attempting to codify processes, move down the ladder below by gradually increasing the process, balancing overhead cost with the value returned, until you reach a point of diminishing returns.


As you review each of the assessment questions, before immediately applying your preferred perspective, try applying the simple approach above, starting from the top and moving down. Where disciplines are sufficient and procedural rigor adds marginal incremental value, stop. Where the team disciplines are not enough or there would be value in process or automation, go farther. The trick is to focus team energy on creative activities and relegate the mundane to process and automation. Drawing that line is not always easy and will vary as the team matures. As my grandmother used to say, "Salt as you go and you will know when to stop."

Several years ago I wrote an article, From Process to Discipline, which uses a simple approach toward the application of rigorous process vs. inventive discipline on projects. At a micro level, the same approach can apply to the Execution Management activities. Certain situationally unique practices are best guided by appropriate disciplines. Other practices are maximized by more structured, repeatable and consistent processes. I think this is where many teams breakdown. As strong believers in their preferred approach (Agile or Traditional), they fail to embrace the value of the other perspective and miss out on the benefit each brings.

The Execution Management Disciplines of Software Engineering

Admittedly, most of the teams I work with are IT teams -- and more specifically, software development teams. While I have project management experience in several different domains, I am most familiar with and work the most with software development and deployment teams. Coincidentally, this is also where the Agile movement began, and it is still the dominant domain where Agile is applied successfully.

While the practices of Software Engineering are largely technical and often environmentally specific, certain universal execution management disciplines are needed to amp up the speed of any team. Environmental conditions need to be conducive to efficient execution with minimal waste. Tools for the creative process have to allow for safe trial and error, creating feedback loops for learning and improving daily practices. Methods and practices for verifying and validating that the outcome is as expected are essential for consistent quality outcomes. Most importantly, the team has to possess the inherent technical domain knowledge to execute their craft.

The specifics of these Software Engineering practices can be extremely complex and varied. This is exactly why general guidelines at the discipline level are better at steering best practices than prescriptive rules would be. The assessment questions attempt to provide that high-level guidance while allowing you to eliminate or modify them as needed to suit your specific project or circumstances.

The Execution Management Assessment Questions -- Software Engineering

The questions for the Speed Readiness Assessment are specific to the Execution Management Disciplines of Software Engineering. As Agile becomes more pervasive and is increasingly applied to projects and domains outside of IT, I may replace the Software Engineering assessment questions with questions more specific to other domains, for example, marketing, sales, manufacturing or construction. In the interim, if this does not apply to your teams and projects, feel free to replace the Execution Management assessment questions with ones more appropriate for what you are measuring.

As with Product Management, I have proposed a list of a couple dozen assessment questions for Execution Management for the Software Engineering domain. They are grouped into two sections, Development and Testing. I have added these to the Product Management questions from the previous article growing the Speed Readiness Assessment. In the next article we'll tackle the Project Management Disciplines and complete the assessment.

I welcome your feedback and ideas to improve this list. Please check it out. As a special incentive to contribute your thoughts, I will send the final Speed Readiness Assessment tool to anyone who comments on the assessment.

Not all comments are posted. Posted comments are subject to editing for clarity and length.

The comments to this entry are closed.

©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy

Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Got a Question?
Drop us an email or call us toll free:
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.