For crazy out of the box thinkers. No idea is too crazy to be considered here. Bust the paradigms!
Stop Designing IT Projects to Build and Design them for Use
November 14, 2009 at 3:21 am #85463
It’s time to stop thinking about project management as being constrained by time, cost, and scope and start thinking about projects as enablers of benefits.
November 14, 2009 at 4:28 am #85475
Tim, this is a long read but well worth the time. What a great idea to engage the business community all the way from concept to capability by taking a Design for Use (D4U) approach to IT development vs a Design to Build (D2B) approach!
The fact that this group in the UK provides a maturity model makes this idea one that could become a reality.
Wow… What an opener for Way Out of The Box! Thanks for sharing this great idea!
I wonder if anyone in our community has had hands-on experience with this approach.
I also wonder how the Acquisition community would handle such an approach.
November 14, 2009 at 7:02 pm #85473
After several conversations with the director of our fairly small agency, we’re finally starting our first project with this approach. Just starting but I’ll let the community know how it goes.
Since reading about the Benefits Realization framework, I can’t imagine going back to doing a project any other way.
The D4U/Benefits Realization framework is also a deep foundation for my Focus on Efficiency blog posts here on GovLoop.
November 18, 2009 at 3:04 pm #85471
Hey, Tim. I was sharing this discussion with a colleague and he introduced the SCRUM and the newer version of it: eXtreme Programming (XP), which is based on a methodology of getting the ideal to the real in a short iterative cycle.
Are these different or complimentary?
He sent me some reference links:
November 18, 2009 at 5:38 pm #85469
Disclaimer: I all ever knew about XP I just learned in 30 minutes from your links.
It seems like the ideas are similar, and can be complimentary. Both emphasize that there should be a strong relationship between the developers and the end users.
XP seems to place a lot of emphasis on how the development team will change so development is not a one-time D2B process, but a continuing process. Good stuff. The “Designed to Fail” document specifically states the weakest step in the “Planning Phase” is the gathering of user requirements. Here’s where it seems (you know, in my extensive research) that XP can have the greatest contribution to overcoming some of the limitations of D2B, because it changes the way those requirements are gathered and processed by the developing team.
In contrast (although not in contradiction) to XP’s emphasis on how the development team will change, D4U places a lot of emphasis on the user of the technology, and how those users will change. Here’s a quote from Designed to Fail: “However, even if IT successfully builds a system that meets the sales team’s desired requirements, there is no guarantee that the sales force will use it.” So the user’s will need to actually use the system.
More specifically though, users will have to use the system to change what they’re doing so the benefits from using that system can be realized. In D4U/Benefits Realization/Focus on Efficiency there’s a consistent message that the goal of IT isn’t to digitize existing work practices (which is what most people want when you ask them to help you design a system), but IT is an enabler/facilitator of change and change is required so benefits can be realized. There’s a consistent recognition that IT doesn’t provide benefits, benefits can be accrued when people use IT to do something new, stop doing something, or do something in a different way.
Summing up then I think they’re both important because XP will ensure that the developers build a usable system, and D4U/Benefits Realization/Focus on Efficiency will ensure that the system is actually used to meet the goals of the organization.
I’d be interested in hearing what you and your colleague think…
November 19, 2009 at 2:27 pm #85467
From my colleague:
“I definitely agree with the thoughts from (Tim’s post). Information
Systems from a process stand point don’t always make our life easier or in
the given scenario of the sales team “convenient”. Adoption was the most
difficult part of our eTravel deployment for the 17 customer agencies. The
larger the end user audience the harder it was. As you may noticed XP brings
the end user closer into the development process than ever before (BTW:
SCRUM is the preferred way of doing business today i.e. PMI, Agile
recommended, etc, etc.) http://www.scrumalliance.com . It doesn’t totally mitigate
the adoption issue when dealing with large communities, only a well defined
Change Management Program will do that (i.e. Communication and Outreach) but it does bring forth a closer end product that reflects the way people actually do their business.
Here’s some stats reported by the Standish Group Study at XP2002,
Jim Johnson, Chairman: Feature Usage in Software Projects: 45% Never Used;
19% Rarely Used; 16% Sometimes Used; 13% Often Used; 7% Always Used. So if we used D4U and SCRUM together we can deign and build for that 20% of usage (13% Often Used; 7% Always Used). Putting my Exec hat back on I see this as a winner from all aspects i.e. faster adoption, no over builds, end user
efficiencies, etc, etc. All these can be easily measured and converted down
to the almighty dollar.
So as for (Way Out of The Box!), A consideration to merge methodologies/processes between D4U and SCRUM may bring out the best of both worlds.”
November 19, 2009 at 2:49 pm #85465
“A consideration to merge methodologies/processes between D4U and SCRUM may bring out the best of both worlds.” — Absolutely!
The only things I’d maybe add is that the ultimate goal of D4U/Scrum shouldn’t be to “bring forth a closer end product that reflects the way people actually do their business” but to “bring forth a closer end product that reflects the way people should actually do their business.” And ideally the change management shouldn’t be identifying how people how to get people to use the new computer system, but the new computer system should be born out of the change management process (realizing in large organizations it will probably be both).
If you’re up for another long read, I highly recommend Managing the Realization of Business Benefits from IT Investments and for a super long read, buy the book Benefits Management: Delivering Value from IS & IT Investments.
By the way, great stats from the Standish Group!
You must be logged in to reply to this topic.