August 30, 2011

Observations in IT Best Practices: Involving your Stakeholders

Observation #3: IT-Optimized organizations involve their stakeholders early and often

Continuing along the theme of what makes for an outstanding IT department at any company, I've been reflecting on how organizations involve their end users in technology decisions. It seems pretty obvious that before you make decisions about what technology to implement and how, that you would consult with the very people that are going to use the technology just what their needs are. However, that is not often what happens.

I can't tell you the number of times I have received requirements documents or RFP materials that were written entirely by someone that will never use the very technology that is going to get implemented.

Generally this happens in a few ways. The first, some well-meaning executive or manager singlehandedly drives the acquisition of a technology that the company has just 'gotta have.' He or she images the best-case scenarios, writes out all of the requirements for all the different users, then interviews the product vendors to see if their wares match his or her documentation. That project sponsor then either goes to IT to implement the technology that he or she selected, or, if the sponsor has budget power, gets the software vendor or an integrator to implement the technology, bypassing IT altogether.

The second approach is when IT is sanctioned by some executive to go out and do all the legwork, the research, the requirements documentation for, and the procurement of a new technology. Very smart functional analysts with no situational fluency or subject matter expertise are employed to put those requirements together, but often this is done in a vacuum without ever communicating with the stakeholders of the proposed system. The analyst will often try to convince users after the technology is implemented to change their requirements or workflows to meet the capabilities of the software. That doesn't usually end up going well.

With respect to the first approach, this is an executive management problem. The C-level team must agree that any requisitioning of new technology must be preceded by the systematic elicitation of business requirements, stakeholder requirements, then solution requirements - in that order. The best way to safeguard that the investments you make in technology meet your business needs across the enterprise is to ensure that the your organization has the standardized capability to elicit, validate, and verify requirements directly with the various stakeholders that will use the system. It stands to reason that an IT department set up as a service bureau to the various businesses should have this standard capability. In essence, IT must be able to partner with the business to help draw out the 'what' of the business before going to the 'how.'

The difference between IT partnering with the business to elicit document requirements vs IT just doing legwork by itself as described above is that if IT drives the actual requirements process, then it increases the risk of missing mission-critical requirements and workflow details. We technologists sometimes like to think we are mini-Messiahs that can think up then document what our customers need pre-emptively. Sometimes the C-level team wants that messianic capability from IT, either because the execs are too busy or because anything technological seems too hard, or something the IT guys should be handling anyway.

The important point that I'm trying to make here is that there should never be a time when IT is not involved in requirements elicitation and documentation, but likewise at no time should IT be defining the stakeholder requirements elicited in that process. The best practice is for the IT functional analyst to facilitate requirements elicitation sessions with a sampling of stakeholders that will be using the technology in the future. Thereafter, as you roll out that technology, you'll have the same stakeholders holding a vested interest in the success of that platform. That makes for a better climate for collaboration, including user acceptance testing and rollout support from your business customers.

Posted at 03:43 pm by Joseph Bachana

Add comment

• IDEAlliance Webinar on Innovations in Multichannel Publishing 02/08/2012 - 15:01
• On Measuring the Progress of your Digital Asset Management system rollout 02/07/2012 - 13:14
• Drupal 8 Goals Emerging - Interview of Dries Buytaert by Ron Miller 01/21/2012 - 17:29
• Apple iBooks Author and The Walled Content Garden 01/20/2012 - 12:59
• Ten Best Practices in Requirements Analysis 10/06/2011 - 01:55
• Do PMPs make Good IT Project Managers? 08/31/2011 - 13:37
• Critique of Adweek article by Erin Griffith on "CMS Woes" 08/22/2011 - 23:26
• Article on CMSWire.com about Adobe's Aspirations into Customer Experience Management 08/20/2011 - 00:34
• Observations in IT Best Practices: Aim Before You Shoot 08/01/2011 - 12:46
• On Innovation, Research and Development, and Passion 07/29/2011 - 14:59