AJC Playbook: How to Implement Strategic Projects?

Now that you know WHAT you are going to do, it is time to implement.

There are two facets to this.  First is the Project Management Office or PMO, keeping tabs at the high level of all initiatives and continuing to prioritize between existing work (back to WSJF). Second is the individual project implementation work.

At AJC, we bucket all of this under an Agile Operating Model, or AOM.

AJC’s Agile Operating Model considers the three components of traditional Project Management, Features, Time, and Cost, and positions them in a realistic way to life. Specifically, we assume that change is the only constant, and in order to be able to respond to the reality of an unfolding project, the team needs to be empowered to adjust when necessary.  That being said, results are absolutely required, so the team also needs to be empowered to deliver on specific commitments.

The visual below shows how when the Features (or results) are completely fixed – meaning that you cannot adjust what you plan to deliver – often the schedule and/or the costs must be variable. Trying to hold all three corners of the triangle firm typically results in questionable quality over what is delivered.

agile-triangle

Conversely, if one wants results in a fixed time period and budget/cost, then there must be allowances that the features – quality and complete features – cannot be too voluminous, and must therefore be variable.

The fixed Time and Cost factors here, therefore, are SHORT – with the emphasis placed on delivering truly functional results in short increments of time with the team and budget you have allocated to that time period, and re-prioritizing the next time period for the next round of features with again the fixed cost or budget.

One method for doing this is to use Scrum, wherein a cross-functional and dedicated team reviews features that a Product Owner lists in priority of importance and/or dependencies and self-determines from the top of the list how many features they can commit to in a Sprint duration, typically 2 weeks. They then perform focused work monitored by a Scrum Master, who keeps the accountable to the process, for that two week period to deliver on those promised commitments and showcase their results in an open Review at the end of the Sprint.

Many clients cannot fully devote themselves to this ideal Scrum method of implementation. Typically their cross-functional team members have “day jobs,” and are only able to participate in “project work” on a part-time basis – fewer than full time hours each week. Additionally, the different features or components of the project do not always require the exact same team, so they need flexibility to assign different team members to different Sprint iterations. Finally, they do not always have someone with the skillset to play the Scrum Master role, and need help staying accountable to the process and not allowing distractions to detract from results.

That is why AJC developed our Agile Operating Model.

What is an Agile Operating Model?

AJC’s Agile Operating Model take into account these challenges our customers have and adapts the Scrum methodology to maintain the benefits of focused and quick-iterative results with the needs for flexibility of the organization’s team members.

We assign an Agile Project Manager (APM) to work with the owner for each project or initiative to develop the prioritized list of features, milestones, or improvements from the Strategic Planning process and help understand the team members who should play a role in each (i.e. the Cross Functional Team) – this is the “Backlog.” The APM then assembles the team members from the top several items on the list and facilitate their commitments to how much of that they can accomplish in a 2-week “Sprint” cadence. Sometimes this means dividing the feature or milestone into sub-tasks and committing to a portion of those for the next Sprint.

Once the team knows what they will be working on, our Agile Project Manager coordinates the sprint much like a Scrum Master, though with the understanding that team members can only dedicate part of their day to the work. The APM schedules and facilitates huddles, ranging from 3-5 per week and only 15-20 minutes long – to discuss 3 things:

  1. What did you complete yesterday?
  2. What will you do today?
  3. What roadblocks did you encounter or do you anticipate?

The Scrum Master then works in the background to try and eliminate roadblocks while the team works on the activities over which they have control (often the group comes up with actions the team can do themselves to eliminate the roadblocks as well!). At the end of the Sprint period, the APM coordinates and facilitates a Review, Retrospective, Planning process – or RRP.

The Review is a short, 30-minute meeting, whereby the team showcases the work they completed in the past sprint. If it is configuration in a software system, they will demonstrate the functionality. If it is creating a new form, they will show it off. If it is preparing a training, they will preview it at a high level. The Review is open to “anyone,” and required attendees are the team itself, as well as up and downstream stakeholders within the company, as well as managers for the Sprint team, the owner of the project or initiative, and the APM. Note, if the team has not completed their full commits in that Sprint, the unfinished items return to the Backlog and are reprioritized with the remaining items there; likely at the top of the list, though the Project or Initiative Owner makes that determination. For example, if the Sprint team committed to a PowerPoint Training and it is done except for a few complex visuals, the Project Owner may decide that it is done enough to allow those visuals to be deprioritized until some other work gets finished first.

After the Review, the team will go through a facilitated Retrospective where the APM asks each person and the group as a whole to discuss what went well in the last Sprint, and what they could do better for the next one.  At this point, anyone who could be on a future Sprint team can participate to learn.

Armed with these areas for continuity and improvement, the team then goes through the Planning process to determine what commits they will undertake for the next Sprint. The APM brings in the possible team members for future prioritized items on the Backlog and the team repeats the cycle.

One additional responsibility for the APM is to keep the Project or Initiative Owner accountable to re-prioritizing the Backlog between sprints. If new features are requested, or certain technical challenges require additional tasks or dependencies mid-Sprint, the APM collaborates with the Project or Initiative Owner to update the Backlog and shuffle the priority to meet the current reality. In this way, the entire process is dynamic to the ever-changing realities of the world and the team naturally will work on the most important things next.

To maintain the integrity of the Agile Operating Model, there are a few critical factors.

  1. Once the Sprint team has made their Commits, these are fixed for two weeks. Reprioritization can only happen between Sprints so the teams can deliver results
  2. Managers of Sprint Team members must be fully aligned to and supportive of the Agile Operating Model and allow their employees to dedicate the part-time hours they’ve agreed upon for the sprint
  3. Managers also must allow the Sprint Team to self-determine the volume of work they undertake in any given sprint; only the prioritized order of the Backlog is within their sphere of influence (though the owner is the Project or Initiative Owner)

If this sounds like a leap of faith, that’s because it certainly can be! Not being able to directly assign work or micromanage daily schedules is often foreign to traditional management. 

However, the benefit is that the team will feel truly accountable to the work they commit to doing, and the results may surprise managers because the team can be creative in how and when the work is done within the Sprint timeframe. Also, once the team gets confidence in their ability to predict how much work they actually can complete in a Sprint time period, the organization will be able to forecast more consistently how long the full project or initiative will take, while realizing incremental results throughout the project.

Establishing an Agile Operating Model, which is essentially a Project Management Office, or PMO can be daunting, and it may be helpful to have a guide. Outsourcing the PMO or AOM can help jump start the timeline for organizations to get results.

Working Genius Note – Project Management Office (PMO) or Agile Operating Model (AOM)

This is where the rubber meets the road, and the Discernment, Enablement, and Tenacity geniuses are in their element.  Discernment helps the Project or Initiative owner prioritize the Backlog and identify resources for each item, and Enablement and Tenacity helps the Sprint team complete the work. There is room for Galvanizing here, though that is largely applicable to evangelizing the model with Managers to ensure they understand their role within the model and empower their employees to be successful working within it. Many companies have employees with the D/E/T geniuses, though they are often dedicated to specific work themselves, and cannot step out to manage the PMO or AOM as a program. It is often helpful to get a partner to assist in this, though many consulting firms prefer to be in the strategy areas. At AJC, most of our team members have D/E/T Working Geniuses, and our model to help organizations accomplish impactful project and change work efficiently lends itself to the part-time nature of running the Agile Operating Model. We also can bring in Change Management support to help evangelize and describe the model better for managers and the whole organization, providing full service to our customers.

Read the previous article in the AJC Playbook Series: How to Prioritize which Strategic Initiatives will lead your Company to the type of growth you want?

Link back to AJC Playbook: Sharing our Methodology (and Running Table of Contents)