8 min read

Project Cost Accounting in Agile | Part 2 of 3

By Amanda Babb on Apr 5, 2019 12:00:00 PM

Second of Three

This is the second of a three series blog. When we last left our intrepid writer, we learned that the secret of Project Cost Accounting in Agile is Nothing. Fixed Teams means Fixed Costs. Fixed Teams means predictable velocity. In Kung Fu Panda 2, however, there is a danger lurking on the horizon: Lord Shen (a peacock) believes in a prophecy which leads him to destroy all pandas in China. He also yearns to regain the respect of his family by conquering China with a new weapon. In many organizations, Lord Shen is the dreaded spreadsheet: the ability to modify project costs based on resource leveling and moving Teams to the work.

Embrace the Past

Let me make this clear: tools are only as effective as the hand that wields them. Lord Shen took gunpowder, used in the making of fireworks, and developed cannons to defeat China. Something that was devised to bring joy to the masses was changed into something destructive which, had it not been for the fortitude of Po and the Furious Five, could have ended disastrously for China. Let's take a look at why project cost accounting can lead us to further victory by embracing our past while securing our future.

The Agile Team Seeks Balance

The Agile Team seeks to maintain balance: deliver the right functionality at the right time producing as much value for the business as possible. Scrum Master, Product Owner, and Team must work together to understand and provide the value. When business value is monetized, it becomes an easy value to track as a KPI, but hard to predict. What did we get for the $260,000 of labor costs we incurred for the team? In fact, what did we get for the $2.6m of costs we incurred for the Agile Release Train (Team of Teams)? If we were able to make revenue on the effort, then the math is simple: subtract the revenue from the costs and we see our net gain or loss. But we all know that actual financial management in any organization is decidedly more complicated. At least in the United States, there are tax breaks for Research and Development, differences between capitalizable and operational funding, and other financial aspects that many people who are much smarter than me spend their careers managing. Is there a way of reconciling our past models with our current and future state of agile? Can we gain the inner peace Master Shifu states Po (and by proxy, the audience) have yet to attain?

PI Boundary

There has been a debate raging on in the agile community around this concept for a few years. While I do not have all the answers with respect to this topic, I have a few ideas. One organization in particular comes to mind where this worked beautifully: a Value Stream with four Agile Release Trains (ARTs) was given their annual investment of $100m to be spread across seven Strategic Themes. The owners of each Strategic Theme came up with a series of initiatives and prioritized them against one another at each PI Boundary. Since Train costs are fixed at the Program Increment (PI) Boundary, if an initiative was completed, its cost was removed from the $100m pool. Any additional variables such as number of Sprints if an initiative was completed mid-PI were accounted for at the PI boundary as well. Simple, elegant, decentralized.

Lean Budgets

However, there was still the need to understand how much of that chunk of money remained at each PI Boundary and whether additional funds could be allocated to another Strategic Theme or another vertical within the company if money was left over. In Kung Fu Panda 2, Po, upon being confronted with a pack of wolf bandits sees a symbol and flashes back to his youngest memories: he's seen the symbol before, but cannot grasp the importance of it. He only knows it's something to pay attention to. Much like when, in SAFe, we discuss the concept of Lean Budgets. We instinctively know this is something to pay attention to, but we still cling to project cost accounting as our method of reconciliation. Below is an example of Lean Budgets in SAFe. 

Project Cost Accounting in Agile past and future

https://www.scaledagileframework.com/lean-budgets/

Value Stream

The Lean Budgets concept strives to balance governance and empowerment while providing a simple funding model for a given Value Stream. A Value Stream is the organizational structure that provides a continuous flow of value through solutions to the customer (aka the Execution Engine). For example, a Value Stream can be a factory or a hospital. It can also be a development organization - as long as it is focused around solution delivery to a customer. Many organizations struggle to define Value Streams and instead loosely group teams together under a resource manager or other traditional reporting structure and call it an Agile Release Train. While effective on the surface, it complicates coordination across efforts. It's not until a common solution and purpose is defined that the organization can move forward. Lord Shen, as a common enemy across districts, aligns the Valley of Peace and Gongmen City. The teams come together with the needed resources to eventually defeat Lord Shen, but not without trials and tribulations. It is not easy to align an organization to value delivery just as it was not easy to eventually defeat Lord Shen.

If Teams are Fixed, Costs are Fixed

As I stated in the previous post, if Teams are fixed, costs are fixed. If Trains are fixed, costs are fixed. The only funding needed to produce a solution is to cover the cost of the Train. And the cost of the Train should be predictable through a PI. Assuming a single Train in the Value Stream, if each project team costs $260,000 per year, then a Train with 10 teams costs $2.6m per year. Divide the cost of the Train by the number of Sprints in the year (26), then multiply by the number of Sprints in the PIs (typically five), $50,000 is needed for the Train in the PI. Provide the Value Stream $50,000 and watch them work.

Once a Value Stream is defined, Lean Budgets then states it is important to "Empower Value Stream Content Authority." Storming Ox and Croc sit, defeated, in Gongmen City prison. It's only when the Furious Five and Po join them and demonstrate their ability to win a single battle that the two become empowered enough to try and save their city. Before this initial battle, there was no plan other than escaping Lord Shen. The Stretch Goal was to also destroy his cannon. There was no meticulously created work breakdown structure. There were no step-by-step dependencies. There was a single solution the Train needed to implement: learn Lord Shen's plan, escape Lord Shen, regroup to create a plan to defeat him. Our Train (Storming Ox, Croc, the Furious Five, and Po) completed their objective and stretch objective simply by understanding their value and executing on a single purpose.

Project Cost Accounting Starts with the Goal

If, as an organization, we instead try to use project cost accounting, we hinder the Train's ability to provide value. Project cost accounting starts with the goal: defeat Lord Shen. To defeat Lord Shen, we need all three Kung Fu Leaders from Gongmen City: Thundering Rhino, Storming Ox, and Croc. If we have all three, we can defeat him in a day and move onto the next project...er...battle. Three resources for eight hours = 24 resource hours. At $50/hour (our typical cost per hour), $1200 to defeat Lord Shen. This leaves the Furious Five and Po to defend a village from wolf bandits who, in fact, are Lord Shen's minions. The solution does not address the problem as a whole: Lord Shen is the root cause of the battles thus causing the Teams to move to the work. As we move through the story, it took the entire Train to defeat Lord Shen in just one battle and had Po and the Furious Five team members had content authority (knowing what Master Shifu knew about Lord Shen), they might have been able to save Thundering Rhino.

Evidence = Value Delivery Priorities

There are three other parts of Lean Budgets we haven't addressed: Provide objective evidence of fitness for purpose; Approve Epic-level initiatives; Exercise fiscal governance with dynamic budgeting. Let's take objective evidence first. The System Demos and DevOps model addressed in the Program Level of SAFe provides the organization the ability to provide objective evidence. Is it working code in production with dark features toggled on? Yes. Value has been delivered to the customer. Did our intrepid warriors escape? Yes. They were able to escape Lord Shen. However, what happens if value was not delivered? What happens if it takes another PI to deliver the solution? Taking the foundational approach from the project cost accounting model, we have to fund the Train for a second PI. Instead of $50,000 to deliver the solution, it is now $100,000 ($50,000 per PI times two PIs). However, if the cost of the Train has already been accounted for, this is a simple shift in priority, not a movement of funding. You don't have to find another $50,000. Instead, you negotiate whether it makes sense to continue the effort or abandon it based on other value delivery priorities. The path to inner peace starts to become clear.

Approve Epic-Level Initiatives

This ties beautifully into the next part of Lean Budgets: Approve Epic-level initiatives. As we established, the funding is there. If after evaluating the fitness for purpose, the choice is to abandon the effort, the Trains and Teams do not disband. Instead, the work changes as priorities shift toward the next Epic-level Initiative - moving the work to the Teams and Trains. The costs remain constant: only "how" changes, not the "what". The Epic-level initiative is still to defeat Lord Shen: it is the approach that changes for Po and the Furious Five ultimately giving them the flexibility to deliver the victory to China. The Teams and Trains shift to the new strategy and work toward the solutions continue.

Fiscal Governance with Dynamic Budgeting

Lastly, we address the final step on the path toward Inner Peace: Exercise fiscal governance with dynamic budgeting. Much like achieving inner peace, this is not something that is achieved quickly. The recommendation from SAFe is this is addressed semi-annually whereas project cost accounting re-evaluates every work effort once complete. If the effort is small (e.g. 1 month or two Sprints), the allocation of funding to the Team or Train must be evaluated off-cadence meaning mid-sprint or mid-PI. Depending on the internal procurement procedures, this can become a Herculean effort for Business Owners, Epic Owners, and oft times, the Team or Train. It is an unnecessary distraction and thoroughly disrupts the execution. Remember the Kung Fu Leaders of Gongmen City. The first battle with Lord Shen was lost when defined to a specific Team without the proper resources and an unrealistic estimate of the level of effort. Subsequent battles also proved project cost accounting failed the Team: the Furious Five were imprisoned, Po was injured and near death only to be saved by a soothsayer showing him the truth of his past.

Using Agile to Secure the Future

Po reached Inner Peace by embracing the tragedy of his past and letting go. However, we have to remember the lessons we've learned throughout the story. Understanding our past makes us better prepared to embrace our future and win battles. Project cost accounting is a great model when running an organization that is aligned to cost centers. But by realigning cost centers to Value Streams, the burden of project cost accounting is lessened and planning processes can become more efficient. When aligning to the quintessential tenet of agile, trust, you, too, can achieve inner peace.

Topics: accounting scaled-agile roi program-increment lean-budgets project-management
5 min read

Project Cost Accounting in Agile | Part 1 of 3

By Amanda Babb on Mar 28, 2019 5:13:43 PM

First of Three

If you've read my other blog posts or watched one of my webinars, you should be familiar with my tendency to intertwine somewhat unrelated concepts together. I like doing this because it gets folks thinking: thinking about serious business and process things in a totally different context. This is the first of a three series blog. Today's topic: The secret ingredient is nothing.

pandaSecret Ingredient

In DreamWorks Animation Kung Fu Panda, Po states to his dad, Mr. Ping (a goose), that he doubts he is his son. Mr. Ping looks at Po very seriously and announces he has something to tell Po. Po, at his most vulnerable, and by proxy, the audience, expects the Big Reveal: Po the Panda is not the son of Mr. Ping the Goose. Instead, Mr. Ping reveals the Secret Ingredient in his Secret Ingredient Soup: nothing. This leads to Po's epiphany that he in fact is worthy, is the Dragon Warrior, and, with the Furious Five, can defeat Tai Lung. Po has had the ability all along and nothing can stop him if he believes in himself.

Project Cost Accounting

Most organizations work with what is called a Project Cost Accounting model. If an effort provides the most value to a specific cost center, the cost center is responsible for estimating costs as well as the length of time for the project. While other costs such as rent, infrastructure, licensing, etc., are factored in, the most expensive resource is the people. The Project Cost Accounting model respects capacity management and resource leveling. If we need to release something in six months (26 weeks) and it will take 26,000 hours: 26,000 hours at 40 hours per week for 26 weeks is 25 people. Multiply the hours by the average cost rate ($50/hour) and the effort will cost $1,300,000 plus "other costs" such as infrastructure and the like. The Project Manager asks for the funding from the specific cost center and the project moves to execution mode (moving the Teams to the work). In reference to Kung Fu Panda, Master Oogway states that Po shall be the Dragon Warrior much to the dismay of the Furious Five and Master Shifu. No effort to dissuade him shall be heard. Raise your hand if you've ever started or managed a project that has left you feeling slightly dazed, incredulous, or rather disheartened.

Iron Triangle of Project Management

So you embark on your quest...er...project. Master Shifu tries to train Po using the traditional methods that were successful for the Furious Five. This leads to hilarious confrontations between the two as little progress is made and Master Shifu resents his time spent with Po. Much like Master Shifu tries to fit Po (and the team) into his model, the Project Cost accounting model adheres to the Iron Triangle of Project Management as well as several other assumptions. The other assumptions include: skill set is equal across resource types, resources are fully dedicated to the project, resources are in place on day one of the project, and work starts day one of the project. We know this is not how it plays out in the real world. Skill sets differ based on experience or technology, resources are usually split between multiple efforts, hiring and onboarding processes delay resource start dates, and work will start on the first day, but not everyone will have work to start on the first day.

An Agile Team is Fixed

The fact remains the Project Cost Accounting model is flawed when managing agile development teams. The strength of the agile Team is their ability to self-organize and create a predictable Velocity. Even before Po joined the Furious Five, Tigress, Mantis, Crane, Viper, and Monkey became legends throughout the Valley of Peace by working well together. An Agile Team is fixed: the number of resources should not change. Project cost Accounting comes into direct conflict with agile planning: because my team of six people is fixed, I will only ever be able to get 240 hours out of the team per week (40 hours per person per week). If the project is estimated at 26,000 hours, it will take 108 weeks to complete and exceeding the release timeline by over a year and a half. While an agile Team removes the assumptions of equal skill sets, dedicated resources, day one start, and day one work start, the 6-month deadline is still real.

Agile Team Dynamics

Tai Lung is headed to the Valley of Peace and he will arrive within a specific timeframe. The Furious Five (plus Po as a noob) then head off to defeat Tai Lung before he reaches the Valley of Peace. As we know, the confrontation does not go well. The team slinks back to the Valley of Peace bruised, broken, and defeated in more than the physical. In-fighting, blame, distrust: there's a reason as adults we relate to kids' movies. In this moment, Po is "that guy". Po's mistakes put Tai Lung's defeat at risk and prolonged the timeline. It also impacted the entire Valley of Peace and allowed danger to further encroach on the innocent. Raise your hand if you've ever felt the same during the course of a project.

If only we had thrown an army at Tai Lung! We could have easily defeated him before he arrived in the Valley of Peace. This incorrect assumption based on Project Cost Accounting then destroys the trust of the PMO in the agile organization. The dynamic of the team as it comes together only by playing off each others' strengths and weaknesses and acting as a team.

Don’t Disrupt the Team

Once the Team is set, it should not be changed based on Resource Leveling or Project Cost Accounting. Instead, moving smaller pieces of work to the Team results in greater throughput. Prioritizing the smaller pieces of work correctly to fit a deadline is critical as well. Po's training was very disruptive to the Furious Five and Master Shifu's Inner Peace. However, once the Team organized and defeated Tai Lung, they were able to save Kung Fu in Kung Fu Panda 2 and expand the lessons learned by Po to a whole village of pandas in Kung Fu Panda 3. The same can be said of Agile Teams or Teams of Teams. Adding a person to a Team to a Train or adding a Train to a Solution Stream based on Project Cost Accounting will disrupt the predictable velocity of the Team or Train and will likely discourage them from innovating or taking risks. The same goes for removing a Team or Train. Adding resources as dictated in Project Cost Accounting will cause disruption and will not allow you to vanquish your enemies...er...complete your project any sooner.

More Secrets

The Secret to Project Cost Accounting in Agile is this - There is no secret. If you follow the concept of an Agile Team, Project Cost Accounting and ROI in an agile framework is simple. If Teams are fixed and Agile Release Trains are fixed, resource costs are fixed. SAFe embraces this within Lean Budgets. It simply requires the organization to completely change how project financials are planned and reported. Stay tuned for next week’s blog, part 2 of 3, where I’ll share more secrets of Project Cost Accounting in Agile. 

Topics: accounting scaled-agile roi project-management
5 min read

Paying for Mistakes: The Cost to Fix a Software Defect and How to Avoid It

By Praecipio Consulting on Oct 9, 2014 11:00:00 AM

In 2002, a study by NIST reported the U.S. Economy spent $59.5 billion annually fixing software defects. Less than a decade later, Cambridge University found the cost to have risen (in 2007 to 2011) to a global cost of $312 billion per year. With technology becoming an ever-growing presence in our society- from smart phones to smart cars- the pressure to build infallible software is at the forefront of companies' minds. A software defect, which can be caused by omitting even one character in pages of code, can have far reaching repercussions.

These kind of non-conformance expenditures spent repairing software defects impact your Cost of Quality, costing your company profit and maybe even your professional reputation. Customer satisfaction fuels the reputation of businesses, and even a small software defect can translate into billions of dollars in lost revenue when people become frustrated over non-functional or mis-operating products. 

"To err is human." So, how do we reduce software defects caused by user error?

With the Atlassian product suite, you have security with well-documented, well-reviewed process capabilities- You just have to begin with the end in mind. This should be the mantra for any software development effort. To start, gathering clear requirements in Confluence will allow a team to have a single point of truth when in the early stages. Developers, QA, Stakeholders, Product Owners, Scrum Masters- everyone should be involved in the process. Before kicking off a new project, ask yourself:

  • What are we trying to create? (e.g. a new feature, an enhancement to an existing product or offering, a cleaner UI)
  • Why are we doing this and why is this a need? 
  • Who are the end-users and how will they be using the product?
  • Where in the application will this sit? (e.g. Is it middleware? Is it database transactions? ) 
  • When can we release this? 

These 5 questions can get ideas flowing. Recommendations regarding this phase include creating user profiles to help determine acceptance criteria. In Agile, the creation of user stories helps here too. By beginning with the end in mind and leveraging Confluence, there is no question as to what the expected function of the product is and what is considered done.

Once the requirements have been reviewed and agreed upon, now is where we start tasking. Within Confluence, selecting text and creating Jira tickets is easy once the applications are linked. These issues should be created with the mindset that after an iteration, the issue is complete and potentially shippable. 

Fail fast... then fix it!

These checkpoints in the SDLC process have the opportunity to make or break a deliverable's release, reducing extra costs to the company. Depending on the phase in which the defect is introduced, and how long it takes to catch, the losses can quickly add up. Finding an architecture issue in the construction phase will cost 10 times as much than if it were caught in its starting phase. A requirements issue found in post-release can cost up to 100 times as much to fix than if identified from the beginning. How can you ensure you're shipping a defect-free product that won't cost your company profit or credibility?

Take a moment to think about what potentially shippable means. These items have been developed, tested, re-tested, merged, and are ready to meet the outside world. With a click of a button in Stash, these items can be merged with the Master Branch and are now available for use. But to get to this point, the Scrum Team must have had some way to develop and test and merge and flag issues without affecting the Master Branch or Production System. Here's where integrating Jira, Bamboo, and Stash come in handy. You can create a feature branch, develop against it, and merge it with everyone else's branches to ensure there are no defects. Bamboo will see the new branch and build. Fail Fast. Within a short period of time, the team can see what they did (or didn't do) to make sure the units are potentially shippable- troubleshoot, fix, then merge again. When a build fails or a branch doesn't merge, defects can be filed in Jira and added into the Sprint. 

Accidents will happen.

Even with multiple checkpoints in place for accuracy, a user may spot a defect. In this case, leveraging Jira Service Desk can provide immediate feedback to customer service regarding the problem. By providing a way for customers to communicate their issue immediately, you are able to respond to their complaint- preserving the reputation of your business and gaining important information on what went wrong (so you can avoid it next time). Everybody makes mistakes- it's how (and how fast) you fix them that leaves a lasting impression with customers. 

Limit Defects, Avoid Loss, Increase Productivity

With the Atlassian product suite, user errors that create defects in software are identified and weeded out before your deliverable ships, allowing you to continually increase profit and get solid results. Best practices in robust tools like Jira, Confluence, and Stash help your organization achieve traceability and thorough documentation through continuous integration. Leveraging administrative and reporting functions, including permission setting and customized workflows, you can track project development and identify blockers in real time to mitigate profit loss. Atlassian further stacked their product line to increase visibility and keep deliverables on time and defect-free with their new offering, Jira Portfolio

Million dollar profit or million dollar loss? The omission in a single character in one line of code can be catastrophic to your deliverable, so early detection is paramount. Atlassian helps you catch those bugs before they turn into an infestation and with our extensive knowledge of best practices and process optimization around the product suite can maximize your defect defense. Learn more about how Praecipio Consulting can help you avoid those costly errors. With the money you save, you can treat your team to an Atlassian training course!

Topics: blog scaled-agile best-practices bitbucket confluence process-consulting roi consulting-services jira-service-desk marketplace-apps
2 min read

The ROI of BPM: A Realistic Approach

By Praecipio Consulting on Jun 22, 2010 11:00:00 AM

If you search for “ROI of BPM” in Google, you’ll find a host of ROI calculators and links that will “MAXIMIZE” your BPM ROI. The query results are no surprise. ROI matters most in BPM – it’s the bottom line.

There’s little doubt that most BPM initiatives generate a positive ROI. A recent Gartner study found that 80 percent of enterprises conducting BPM projects will experience an internal rate of return (IRR) better than 15 percent. The study took responses from 20 companies that had completed 154 BPM projects, and 95 percent of the companies experienced more than a 90 percent success rate among their BPM projects.

Successful BPM projects use process automation to make the business more efficient – allowing it to quickly respond to changing market conditions. That efficiency yields savings. The more savings there are, the higher the ROI – and the higher the ROI, the happier the stakeholders.

The problem with ROI, however, is that it doesn’t benefit the entire enterprise at once. Most successful BPM projects involve multiple tangents of the enterprise: IT, Sales, Legal Matters, Marketing. Each department has their own processes, and therefore their own BPM solutions. While the BPM automation software being leveraged by Legal Matters may improve efficiency by 30 percent in its first week, Sales may not see improvement until the beginning of the next sales cycle. BPM success occurs on a case-by-case basis.

The truth is, large-scale investments are sensitive projects. If you’re putting a large sum of cash into a solution, you expect success – and may feel anxious or sensitive until you have tangible results to ease your nerves. If another department experiences immediate results after deployment, it will be difficult to maintain your confidence in your own solution. The discomfort is only natural.

That discomfort, however, shouldn’t distract anyone from the facts of the matter. The facts remain that BPM impacts individual processes differently. The variables are these:

  • Complexity of the process. Some processes have two steps, some have 20.
  • Complexity of the solution. Tailoring a solution to fit perfectly takes time.
  • Employee buy-in. A solution only works if people use it…
  • Training/understanding and adoption rates. Most people are creatures of habit, and naturally opposed to change. Teaching people how to use new software eases nerves and builds confidence, increasing adoption rates.
  • Technological integration. Ensuring that multiple systems agree with one another can be a tedious process.
  • Sales climate. The less business, the less active processes. Success rates and savings figures may correlate with overall revenue in a fast-changing market.
  • The process itself. Some processes are done hourly, some monthly. You can guess which one will produce results and savings more quickly.

Additionally, it’s sometimes difficult to see ROI in the shadows of the BPM project’s cost. The business will be searching for financial fruit as soon as solutions have been planted, but the savings may not offset the cost for a year or more in some cases. A $200,000 project that yields $100,000 in savings annually won’t hit the black for two years – but will yield $300,000 in five years’ time.

The ROI of BPM, therefore, is very subjective. In the end, a successful BPM implementation will yield savings to the entire organization, department by department, year by year – offering more agile solutions than simply maximizing productivity.

Patience, perseverance, and perspective ensure success…

Topics: blog automation bpm business efficiency enterprise management process roi value collaboration it

Praecipio Consulting is an Atlassian Platinum Partner

This means that we have the most experience working with Atlassian tools and have insight into new products, features, and beta testing. Through our profound knowledge of Atlassian environments and their intricacies, we can guide your organization as you navigate these important changes.

atlassian-platinum-solution-partner-enterprise

In need of professional assistance?

WE'VE GOT YOUR BACK

Contact Us