Getting Enterprise Software Development Requests from Speculation to Articulation

In my experience, most scope creep in enterprise software projects manifests as “feature-itis.”  This is the demand for some custom feature to be added to packaged software, by some stakeholder.  In many cases, the requested feature / behavior / report is required by some authority, internal or external, and driven by compliance.  These generally (but not always) qualify as “Must haves.”  In other cases, closer inspection reveals the request to be a variation of “We’ve always done it this way.”  These generally (but not always) end up in the business process re-engineering pile.  And in still other cases, it’s a desire for something completely new.  The stakeholder wants a capability they are currently living without, because they believe this project is an opportunity to get their wishes fulfilled.  When asked why they need this new capability, they speculate about what they could do if they had it.  Consequently, I refer to them as “If I had” requirements.

“If I had a boat, I’d go out on the ocean.

And if I had a pony, I’d ride him on my boat.

And we would all together go out on the ocean –

Me upon my pony on my boat.”  — Lyle Lovett

Now, don’t get me wrong: there are a lot of good innovations in the “If I had” category.  But things haven’t changed much since 2002, when Jim Johnson of The Standish Group noted that only 20% of software features are regularly used, and over 60% of features are rarely or never used.  Even today, most of the business value derived from any premises-based software or SaaS implementation comes from the most common or high-value-added use cases.  So it benefits the organization to focus scarce resources on those high-value cases.  That doesn’t mean we should stifle innovation; far from it.  We simply need to ensure the selection process is sufficiently rigorous.  And one the best tools for driving that rigor is enforcing the use of user stories, so common in Agile methodologies.

“As a <role>, I want <goal/desire> so that <benefit>”

Re-structuring the requirement as a user story forces a more specific articulation.  It also makes the proposal less about the person proposing the change than about a role.  This allows the proposed requirement to be better (and less emotionally) evaluated for business value.

  • Articulating the role helps drive the conversation about who benefits.  Will the beneficiaries be the people who will bear the incremental cost and risk?  If not, are their interests important to overall success?  I remember writing a massive audit report for one project that was run once and never used again, since the stakeholder left the organization and no one else cared.
  • Articulating the goal or desire helps drive the conversation about how to achieve it and keep it in operation.  The cost of delivering and maintaining the new capability is largely a function of the solution chosen.
  • Articulating the benefit drives the conversation about the business value that will be derived from this proposal.  Saving ten hours a week is significant, but at what labor cost?  If accuracy will be improved, what cost savings will be realized?

As practicing IT project managers, we want to guide our project stakeholders who are practitioners of other arts and sciences to effective solutions.  We don’t need to match their level of subject matter knowledge; we simply have to facilitate their ability to articulate their requirements.  Of course, I doubt Lyle Lovett could re-phrase his wish for ponies and boats as a user story, and even if he did, I doubt you’d want to sing it.  But some desires are better sung about than added to a development backlog.

Yet Another Way to Fail

The Ponemon Institute (sorry, that’s just a little too close to “Pokemon”) recently concluded a study on behalf of Watchdox, the self-described “preferred document-centric security solution.”  Key bullet points describing the study, which was based on a survey of 622 IT and security practitioners, include:

“71% percent of respondents say that controlling sensitive or confidential documents is more difficult than controlling records in databases.”

This is hardly a revelation.  Most documents are created ad hoc, using MS Office or something similar, and stored wherever the author feels is appropriate.  Records in a database are typically created and maintained via a purpose-built application, which is controlled by administrators.

“… 63 percent … do not believe they are effective at assigning privilege to employees, contractors and other insiders whose jobs or roles requires access to sensitive or confidential documents.”

Of course, Watchdox sells precisely the cure they need for this ailment!  All they have to do is buy this wonderful product, and then start doing their jobs effectively!  Note that this takes time to set up, because Watchdox needs to know who needs access to which documents under what circumstances.  Note that these controls will take a lot of time to establish, and require the authors of these documents (if you can find them) to make a lot of decisions.  Because it isn’t enough to place these controls on new documents; you’d need to retrofit them to the existing base of documents.  And along the way, someone would need to review these decisions to ensure that they were being done uniformly.  That’s a lot of time required from a lot of folks, many of whom are probably busy doing their regular jobs.  And now some IT project manager is going to ask them to determine the appropriate security for every potentially sensitive document they ever created and stored on some file server?

Ever wonder why so many enterprise-level projects fail?  Sometimes, it’s because someone decides to fix a problem owned by everyone, when not everyone has the time to devote to fix it.  Let not your reach exceed your organization’s grasp.

What Are Our Change Control Procedures Trying to Control?

Back in November, I wrote an article about the life cycle of a change request, and noted that fifteen of the forty-two processes documented in the PMBOK may produce change requests.  More recently, I’ve had occasion to ask: what are our integrated change control processes trying to control?  Because it’s obvious that some projects need to facilitate changes and some need to resist changes, based on the larger context of the organization and the goals of the project, in terms of the constraints under which the project was initiated.  In short, different projects need to optimize for different parameters.  So let’s consider some alternatives:

  • Optimizing for schedule – if a project has a drop-dead date that can’t be adjusted, then change control should facilitate changes that reduce risks associated with meeting that date, and resist changes that increase the risk of delivering late.  Note that such dates tend to be assigned by some external authority, for reasons that can’t be seriously challenged without also considering cancellation of the project.
  • Optimizing for cost – if a project has little or no tolerance for cost over-runs, then change control should facilitate changes that reduce risks associated with cost increases, and resist changes that increase the risk of cost increases.  This is especially true if the project is being performed under contract.
  • Optimizing for quality – if the deliverables of a project warrant placing a premium on quality, then change control should facilitate changes that reduce risks associated with errors, and resist changes that increase the risk of errors or defects.  If you’ve ever delayed a roll-out in order to remove critical defects from a software product, you know what this is about.
  • Optimizing for compliance – some projects have external requirements that are absolutely non-negotiable, and all other considerations are secondary.  Let’s face it: you can’t accept unnecessary risks with some projects, like payroll and other financial calculations, or avionics.
  • Optimizing for value – if a project is to be truly transformative for the receiving organization, then change control should facilitate changes that add value without unduly adding risks and resist changes that add more risk than is warranted by the value added.  When people extol the virtues of an Agile approach, this is usually  what they have in mind.

Note that I’ve expressed this in terms of managing risk; while you can always argue a business case for a specific change, integrated change management has to consider the totality of the project, and the overall risk profile.  We should resist adding the widget that breaks the camel’s back, and facilitate adding the one that improves the overall outcome.

There are probably other parameters for optimization.  If you can think of some, please add your comments!