Requirements Failures for Major BPM Initiatives

Scott Francis
Next Post
Previous Post

123Texas hasn’t had much luck lately with state-sponsored software projects.  In some cases, working software can be turned off if it was found that procurement processes were undermined.  In a case recently coming to light, Texas is doubling down on software that doesn’t work – but we can all rest assured that they followed all the purchasing P’s and Q’s.   Lesson learned – follow the procurement rules.   Such is the world of politics and software deployments. This OAG project with the State of Texas  is near and dear to my heart for a few reasons:

  1. It is right here at home in Austin, Texas
  2. Our taxpayer money is being spent on this project
  3. Child support processes are a big deal.  They should be done right. Improving them is a great cause and mission.
  4. This is a business process management project at its heart, or should be.  Unfortunately it was cast as a database project. (sigh)

This project’s failures have many roots.  We wrote about the vendor selection process already, and how it can be victimized by seven failures (at least!).  In this post, we’ll turn our attention to requirements. 

Another “root cause” was likely the requirements produced from an earlier phase.  Many said the requirements blueprint was to blame. $46 million was spent to produce it over 3 years.  And I have to say, without having read a word of it, I’m sure that it was a waste of the paper it was printed on by the time it was done.  I and the companies I’ve worked for have done 100’s of successful software projects, if not thousands.  And none of them spent even one tenth of the amount of money the Attorney General’s office spent on requirements. 

Anyone in the software business, truly, would tell you that by the time 3 years are up, your requirements are out of date, at best. Out of date is another way of saying, “wrong”.  Anyone in the software consulting business worth their salt would say the same thing.  In the BPM world, every project BP3 ever did in the first 6 years of our existence cost less than $46M. 

Common requirements failures?

  • Too many requirements – burying the development team under pure volume.
  • Lack of prioritization around clear and simple objectives and values. 
  • Assuming requirements won’t change within 6 months. Not 100% turnover, mind you. But we have to accept that requirements change.  It is the only way to run a business process program.
  • Requirements that prescribe the implementation details as well as the needs ( when you see words like “design” and “blueprint” in your requirements, you’ve probably crossed that line ).
  • Spending three years on requirements
  • Spending more than 95% of IT projects on the requirements
  • Failing to adopt an agile approach to allow requirements clarification to coincide with prototyping and confirmation with working software
  • Capturing extremely specific rules rather than the real business needs

I could go on.

A software quality group hired by the State of Texas had their own assessment of the requirements phase, arrived at with no input from BP3 on this topic:

“It was not worth the paper it was written on,” Krasner said. Deloitte was paid $46 million for that work. The initial contract was for $1.8 million, but the state kept renewing it as Deloitte continued its work.

So why does a company accept $46M in requirements development or blueprint development? Because state rules say that they can’t do both requirements and delivery.  And because the money was there for the taking with no consequences. No delivery risk to Deloitte in those requirements.  At 22,000 requirements, the price-per-requirement to document them was $2000. At a minimum, if there are 22,000 requirements, break it into smaller projects…

Why did Texas proceed given the advice that Krasner gave them?

Krasner says he took his concerns about the playbook to state and federal officials. Their response, he said, was, “That’s probably true.” Yet they decided to forge ahead.

What do you do when you lead the horse to water, but he won’t drink? 

We can relate. More on that in another post, about choosing user interface technology for BPM projects…

 

  • Derek Miers

    BPM projects are no exception – almost all so-called BPM failures relate to this fixed mindset in the waterfall approach which was all we could do in the 60s and 70s (but still hangs on).

    In the end, it’s like planning a long holiday and assuming you might not change your mind on which attractions to visit.

    • This is so true. The post, as written, is too specific by calling out BPM. This is true of any IT project. Although, I do think it is even more obviously the wrong approach for BPM.

      I might have to use that holiday example!

  • “state rules say that they can’t do both requirements and delivery” ? Really? So the state doing agile is basically against the law? Really terrible if true.

    • That’s correct, at least for certain kinds of projects/efforts – possibly governed by a dollar limit or somesuch.

      • Also, not “against the law” per se, but against regulations. those regs might not have the force of law, might just be procurement rules, for example.