In Part 1 of this two-part post I talked about the changes that are needed in the area of HR to enable true organizational agility. In part 2 I tackle the Finance group.
The Finance group in many organizations (and I’m admittedly oversimplifying and generalizing here) have become known as the ones who tell you what you can’t do and especially that you can’t do it in a short period of time.
If the HR group has seen themselves as an extension of the legal department, where procurement is concerned, most finance groups are the legal department on steroids.
Another area where this has happened is the protection/promotion of shareholder value (look-up Steve Denning’s excellent series at Forbes.com on the folly of the continued emphasis on shareholder value).
As organizations move towards becoming more Agile, procurement needs to be simpler, faster, and be driven by value delivery goals. This can be done while still following all required transparency, legal compliance, and cost-containment parameters.
Agile Procurement reduces complexity and saves time and money
If procurement groups were to adopt Agile approaches in how they run procurements they would find that Agile procurement processes:
- Take less time
- Are a lot less complicated (especially from a documents perspective)
- Actually procure what the client really needs – and only what they really need
I know this to be true, because I executed a commercial software procurement using this approach for a government agency. When I arrived on site I was presented with a 246-page RFP document that a similar agency had used to procure the same type of software. The procurement process had lasted more than a year and more than a year after the procurement itself they were still not finished with their implementation.
Our results from using an Agile procurement approach?
- By prioritizing business capability needs using Agile principles, we were able to reduce the RFP document size from 246 page to an 8-pages with accompanying spreadsheets for the vendors to complete (no bound and printed responses were allowed by responding vendors)
- The reduction in size and complexity was due to us only asking for capabilities the agency deemed to be of business value (indicated by Very High, High, or Medium) and eliminating those that were not of business value (indicated by Low and Very Low)
- Actual expenditure on the procured software was less than 10% of the original expectation of expenditure – yes less than 10% – as we only evaluated those things that the client really needed
- Vendor responses to the RFP could be evaluated much faster by the evaluation team. We did the entire response evaluations in less than a week and that included board-room demos for the top 3 ranked vendors
Agile can reduce what you have to pay the Taxman
Capitalizing asset investment based on the new ways of working can improve the bottom line. In Why Should Agilists Care About Capitalization?, Dr. Dan Greening claims:
- Scrum teams create production cost data that are more verifiable, better documented, and more closely aligned with known customer value than most waterfall implementations. Better reporting can mean significant tax savings and greater investor interest. Agile companies should change their financial reporting practices to exploit Scrum’s advantages. It might not be easy, but I did it.
- I restructured software capitalization…during an all-company Scrum transition at a 900-person software company, we delighted auditors, gave more insight to upper management and raised more internal money to hire developers. We gained millions in tax savings, by using Scrum Product Backlog Items to more accurately document and capitalize our software work.
His blog post gets into the more detailed accounting and financial aspects of how this accomplished (I am not an accountant…:) ) – but the point is that if your firm produces software products for the market, and if they already are or are planning to use Agile practices, your ability to change how you capitalize that investment using Agile approaches can significantly affect how much tax you have to pay. All goodness.
He concludes by saying that the move to capitalizing asset investment based on Agile:
- ..can require a lot of negotiation, planning and process changes to do so. However, your engineering group may be able to hire more engineers, your company may be able to reduce its tax burden significantly and your company’s financial reports may stabilize. The value of these improvements may be in the millions.
So while it would certainly be a bit of work to set-up, it pays off for years to come. What’s not to like?
Selecting your Business Partners
Moving your organization towards creating its Agile ecosystem also extends beyond your own walls – to your business partners. For example, if you plan to use external development teams to build a portion of your product they need to be using Agile practices as well, otherwise you will encounter intransigent dissonance in the flow of work between your team(s) and theirs that cannot be easily overcome.
When we did the Agile procurement I mentioned earlier, one of the things we noticed was that some firms were comfortable with the approach we were using (as they used some form of Agile themselves), whereas others had difficulty understanding why we only had an 8-page RFP, and why we did not want any bound and printed RFP responses.
While it ultimately was cheaper and faster for those who did respond to prepare their responses according to our approach (they had to submit their spreadsheets along with PDFs of any supporting documents on CD), some firms actually chose not to respond due to the approach that we were using.
The vendors who responded clearly understood what our goals were, and the winner was able to work seamlessly with our team as we were in sync. The cultural fit between us due to their prior adoption of Agile practices made it easier for both sides to collaboratively implement the new system.
Organizational agility is not achieved by simply adopting Agile in just your software development teams. As Steve Denning noted, you need to create an Agile ecosystem.
In this two-part blog post I noted the two areas of your organization that I believe have the greatest influence over how successfully a transition to organizational agility can be in creating an Agile ecosystem – HR and Finance.
What do you think? Are these two the most important groups (outside of software/product development) to tackle first in the move towards creating an Agile ecosystem?
Which groups would you choose instead?