4 Techniques for Improving “Agile ERP” Integrator Accountability

There’s no denying that Agile has transformed application development since the “Agile Manifesto” was first published in the early 2000s.  Its impact on ERP delivery methodologies has been equally profound, although the adoption of Agile has in no way lessened the PMO’s responsibility to ensure that every aspect of the project is being actively managed.

Moreover, Agile has made the PMO’s job more difficult in several ways. For example:

• As governance and approval processes struggle to keep up with the barrage of change requests, the Minimum Viable Product (MVP) gets lost amidst an ever-changing backlog.
• Project plan maintenance and resource planning can become haphazard and sloppy, little more than byproducts of the process instead of tools by which to manage it.
• The critical path starts to feel like a moving target and becomes almost impossible to manage.

To be clear, Agile itself is not the issue. Rather, the problem is that much of the management information needed by the PMO to make effective, timely decisions can easily get lost or obfuscated in Agile ERP integrator tools like JIRA.  And perhaps even more concerning, standard Agile metrics have the potential to hide developing issues and mask poorly performing processes.

Here, I want to consider some strategies for gleaning critical information from standard Agile ERP integrator tools like JIRA.  This will not only empower your PMO to be more effective, but also help you to keep your vendors accountable.

1. Governance Breakdown and Managing Scope Creep

Scope creep has long been the bane of every PMO, and ERP projects are no exception.  The volume of change requests can quickly outpace your PMO’s ability to review and approve them in a timely manner, which often leads to:

• Stakeholders circumventing the governance process and going directly to the development teams.
• Delegation of approval authority to functional / development team leads.
• “Informal approvals” which give your SIs the green light to keep working apart from formal, documented decisions.

Regardless of the shortcut, though, as requests start finding their way into the development pipeline, they can quickly sabotage even the best project plans.  Moreover, since Agile philosophy encourages you to ingest every idea and request into your product backlog, tools like JIRA can compound this problem.  The ease with which JIRA allows you to capture new requests creates an influx of apparent requirements that can quickly overwhelm your governance processes and disrupt your development teams.

To make matters worse, typical Agile metrics and charts can seemingly indicate that your teams are firing on all cylinders, when the reality is that you don’t have enough remaining sprints to complete the MVP in time for integration testing.  This may seem counterintuitive, but burn down charts only tell you if your development teams accomplished everything that was planned for a given sprint.  What they don’t tell you is that ten percent of the completed user stories actually displaced work that is essential to delivering your MVP on schedule.

This dilemma creates a false sense of security that jeopardizes your timeline and increases the likelihood of a change order to extend the Realize/Build phase. Furthermore, you can be sure that this unplanned work will eventually manifest itself as a surprise change order from your SI to cover the cost of completing it.

In other words, whereas change orders are supposed to release funds for additional scope that has been estimated, planned, and jointly agreed to, these change orders are effectively “retroactive invoices” that companies feel virtually compelled to pay. For even though a well-written contract gives you the theoretical grounds to reject any change order for work undertaken apart from formal governance processes, in practice it can be less of a hassle to simply pay it than to try and adjudicate the approval status of the user stories in question.

2. Highlight Your MVP

Fortunately, JIRA is nothing if not…agile.  Thus, one way to gain visibility on MVP progress is to create a “Governance” attribute that indicates the disposition of every user story and epic. This attribute should be tracked independently of the normal status attributes in JIRA, which are primarily used to track the state of an item’s related workflow process.

The range of valid values should be strictly controlled to drive the right prioritization and synchronization of activities across project sub-teams and workstreams.  For example:

• MVP – Coming out of the Explore/Discover phase of the project, all the epics and stories that have been approved should be tagged as your “MVP.”  This set of MVP items becomes your baseline within JIRA and will allow you to generate MVP-specific metrics (like MVP burn up/down charts, or MVP value delivered) that sift through all of the stories in the backlog and allow you to focus on the stories that are absolutely required to deliver a viable solution.
• Approved – As the project moves into the design and build phases, new requests will continue to surface and be added to the backlog.  Assuming that a request is approved, it can either be added to the “MVP” or simply designated as “Approved.” For instance:
  • Your finance Subject Matter Expert (SME) identifies a tax requirement that is not optional and thus needs to be included in the “MVP.”
  • Your warehousing SME proposes a value-added custom feature that will enhance the solution but is not an absolute requirement for the initial deployment.  This would get “Approved” without being added to the “MVP.”
• Deferred / Rejected – Creates traceability by recording the decision of the PMO to defer or reject a proposed request / requirement.
• Pending / “blank” – This is the default for every new item in the backlog and identifies the new items that have been added since the previous review.

Related to the “Governance” attribute would also be the date that action was taken, or a “Decided On” attribute.  By tracking these two pieces of information, you not only enhance the efficiency and fidelity of your change control process, but you can virtually automate the generation of change orders.

3. Track Your User Stories

You may be wondering about how this approach could be adapted for projects with multiple releases.  After all, you don’t want your teams working on “Approved” epics for “Wave 3” when “Wave 1” should clearly be completed first.  One option would be to create compound values like “MVP – Wave 1” versus “MVP – Wave 3.” But it is probably better to create a “Release” attribute that can be used in conjunction with “Governance” to provide additional views of your backlog.

Another useful attribute might be “Build,” which allows you to prioritize the planning of particular user stories in “Wave 2,” even though the completed feature won’t be actually delivered and deployed until the “Wave 3” release.  This technique allows you to preserve the integrity of your epics while pulling forward specific user stories that are pre-requisites for the completed epic / feature.

Of course, there are other variations on this framework that may be required, but the key is to keep things as simple and as clean as possible.  By tracking these key attributes across your entire backlog, you will be able to quickly filter your data and give your PMO the ability to generate burn-up / burn-down charts that differentiate and aggregate user stories by release plan and approval status.

These additional views of the data will provide dynamic, actionable insights into your project status and enable you to answer the following questions:

• How is the MVP completion tracking to plan?
• How is the critical path for a “Wave 3” requirement tracking in “Wave 1”?
• Do we have enough remaining sprints to complete the MVP in time for integration testing?
• Is capacity being used to work on any unapproved items?
• Are “easy” user stories from downstream releases being pulled forward into the sprint plans and displacing the MVP?

Moreover, by creating this extra layer of visibility into governance & release status, you arm yourself with an effective tool to hold your SI accountable.  After all, regardless of how many story points are delivered in each sprint, your contract should allow you to deny payment for work done on any items that have not been approved through formal governance.

4. Better RAID Management

In addition to managing user stories and epics in JIRA, it’s also where you capture and track risks, issues, action items, and decisions.  And just as the “Governance,” “Release,” and “Build” attributes can help you better plan, track, and manage your development workstream, using these same fields to segment and prioritize your RAID items further helps your PMO to focus on the most critical items.

Indeed, just as a single priority field is insufficient to properly segment, plan, and track your product backlog, the standard “High / Medium / Low” status designations on your RAID log don’t provide the level of insight that your PMO needs to operate at peak efficiency.  Because in the same way that knowing a user story is related to your MVP, being able to assess all “Medium” risks that impact the “MVP” for “Wave 1” is probably more important than working through a “High” priority risk that won’t become a problem until “Wave 3”.  You can apply this technique to all RAID items, giving the PMO added confidence that they’ve addressed the immediate concerns of the program ahead of the future risks that may resolve themselves by the time you get to “Wave 3”.

The Bottom Line

While it’s probably true that much of the management information derived from these additional attributes could be extrapolated from JIRA by filtering on multiple date and status fields, dates tend be moving targets.  “Release” timeframes are usually changed over the course of a multi-year project, which makes it more challenging to keep dates 100% accurate than simply creating a few attributes that preserve the intent and high level plan regardless of how the dates change over time.

Rather than be held hostage by the sea of data in tools like JIRA, take advantage of its flexibility. Because with a little planning and foresight, you can leverage the best features of the Agile methodology and simultaneously position yourself to avoid some of the typical “hybrid Agile” pitfalls.

UpperEdge helps clients properly balance managing their PMO to mitigate downstream risks and delays in your program. Learn more about our Project Execution Advisory Services to see how we can help your organization.