Recommended
More Related Content
What's hot
What's hot (17)
Similar to Moving from requirements order taker to business enabler
Similar to Moving from requirements order taker to business enabler (20)
Recently uploaded
Recently uploaded (20)
Moving from requirements order taker to business enabler
- 1. Moving from Requirements Order-Taker to Business-Enabler David Marsh March 25, 2013
- 2. What’s About to Happen? • What is the problem? – And why is it an important one to solve? • Some order-taking scenarios • A better approach • Specific techniques designed to enable business/service success
- 3. The Problem: Consequences of public sector failure are higher than private sector • Governments typically have deeper pockets: result is that they incur higher losses – “a billion-plus of taxpayer’s money went to essentially nothing.” (Lt. Gen. Charles Davis on recent USAF logistics software project failure ) – US government is spending $81 billion/year on IT as of 2012 • Estimated that $20 billion of this is wasted per year (Darrell Issa, Chairman of Senate Committee on Oversight and Government Reform) – The UK Office of National Statistics reported that public service productivity fell 3.2% between 1997 and 2007; at the same time annual ICT spending was between £13-21 billion per year (according to Dr. Martin Read)
- 4. The Problem: Consequences of public sector failure are higher than private sector • Difficultly quantifying the benefits of public sector projects: results in a tougher decision on when to quit spending money • National security may be jeopardized • Freedom of Information (FOI) access and Auditors: failure made public – Ontario’s Social Assistance and eHealth systems are examples • The problems tend to affect many people: private sector comparisons include AT&T’s switching problems affecting 60K long-distance customers in 1990 and 100K LinkedIn passwords hacked in 2012
- 5. My point: the cost of failure is high
- 6. Requirements cited as the reason for failure • Reasons vary, but at the top of everyone’s list are: – Unrealistic or unarticulated project goals – Badly defined system requirements • Incomplete requirements • Changing requirements and specifications • Of course there are other reasons as well... but the point is that we need to “get better at requirements” – But why are requirements so bad?
- 7. Some typical reasons • “No one told us they needed that” – Ontario social assistance system was incapable of raising rates (cost to fix: $10 million) • “Nebulous requirements” – The USAF logistics system failure example • “Hi, we need a new field... status... child table” – It seems to start off so innocently • “We are not allowed to question the business – it offends them” – IT departments do as they are told, acting as passthroughs rather than value-add organizations
- 8. A better way: an engineering approach Business goals and needs Understand root causes and discover real business needs Detailed software requirements Detailed technical specifications Explore and evaluate alternative solutions that meet the needs Technical capabilities
- 9. Traditional techniques for eliciting requirements • Designed to identify root causes of problems: – Pareto (fishbone) diagrams – 5-Whys – Brainstorming • Designed to understand a domain: – Data modeling – Interviews and observation – Process and organizational modeling • Confirm business goals/vision • Designed to define software requirements: – Use case modeling/user stories – Non-functional requirements elicitation
- 10. My preferred techniques • Understanding problems and desired outcomes – Ensure how we measure we are successful at resolving/achieving these • The “spirit” of use cases – Use cases happen to be documented, but they are not documents • Repeating back incorrectly or differently – When people get a little miffed they tell you what they really need • Throwing real situations at requirements and draft designs – Early feedback using real world scenarios
- 11. Problems and Desired Outcomes • 2 questions I ask: – What about the current approach is preventing you from doing your work? – 6 months after the project is complete, someone asks you, “Was it successful?” What measures do you use to tell them yes or no? • The output of these sessions (samples follow) become the driving forces behind the project
- 12. Sample Problem Statements The problem of Affects The impact of which is A successful solution would Restricted store hours due to municipal regulations and labor restrictions Customers The inability to access the store when needed Enable customers to access merchandise whenever they need to, no matter where they are. Marketing, Sales Loss of positive brand image since our products are not available to our customers when they need them Reestablish a strong brand image by making our store the first place to look when renovating. Excessive inventory carrying costs Supply Chain Operations Limited ability to carry large items in stores Limited ability to carry large quantities of all items in stores Enable our store to market all household and hardware items, no matter how large. Facilitate “direct-from-supplier” delivery.
- 13. Sample Desired Outcomes Desired Outcome Objectives Priority Evaluation Criteria Increased Efficiency No lost documents Must The number of tickets opened to find lost documents on accounts is 20% of what it is before the system is deployed. Improved inspection review process Must The turn-around time for reviews of inspections must be 60% of what it is before the system is deployed. Service center team members re-assigned Must Due to elimination of paper files, all staff responsible for handling these can be re-assigned to other work Elimination of the binders means that auditors do not have to travel to the field offices for audits; thus a reduction in the travel budget Must The travel budget for audit is currently $27,600 for the year 2010; this must go away in 2011 Remote machines are no longer needed Should The 54 remote machines are removed from field offices Eliminate sending documents to Iron Mountain, on a goforward basis Must No documents sent to Iron Mountain for accounts effective 1 June 2010 and onwards. Reduction in Operational Cost
- 14. The “spirit” of use cases • The use case model actually reflects the selected alternate solution uc Inv oicing Use Cases Invoicing System This is not a function. It reprsents a goal and a story. Submit Inv oice Inv oice Submitter Approv e Purchase Order Paymenrt System Payment Manager Reconcile Payments The story has a usual set of steps (basic flow, linear) and rare/ exceptional/ abnormal alternatives (lateral).
- 15. Summing up • There is a higher risk that government projects fail to deliver value, and the consequences of that failure can be exceedingly high • “Requirements” cited as the reason for failure – Often due to pass-through order taking – Real analysis of the business goals and exploration of alternative solutions is key to turning this around • There is hope: there are proven techniques for becoming a “business-enabler” instead of an “order-taker”