One of the bigger challenges I see IT leadership facing is participation by other business stakeholders in product development.  Since IT is generally where the rubber hits the road and nifty ideas become reality the IT folks sometimes get left holding the bag for half-baked initiatives.  The next killer app can sound great in a sales and marketing meeting where a 100,000 foot view is as deep as it goes, but when the nuts and bolts need to get tightened down you, the IT leader, can find yourself in a ghost town of participation.

In the performance management, time and attendance, learning management, HR software world such a lack of engagement by all aspects of an organization can lead to software that meets no one’s needs fully and serves the end user (aka: client) only partially.

Fortunately at Achievant our senior staff is locked and loaded and both willing and capable of participating in all phases of product development so that all interests are served and the development process is a rarefied one where the best product emerges at the end due to the engagement of all stakeholders.  If you find yourself in a different environment here are some tips on getting the engagement you need:

1.       ALWAYS invite all stakeholders to meetings where details are going to be hammered out.  You don’t want to exclude a point of view and you don’t want to give someone the excuse they need to not be there when you need their input.

2.       Require review and sign-off on all specifications by all stakeholders.  Physically have them sign a document saying they have read and agree with the details of the new feature.  Having someone put their John Hancock on the dotted line does wonders for participation.

3.       Provide milestone updates once development is under way.  Provide screen shots, partially functionality, etc as soon as you can during group reviews and get agreement from the larger organization that you are on the right track.  This may seem like political CYA, but it’s not.  It gives you the chances to demonstrate progress and verify with the other stakeholders that your development is directionally correct.

4.       Include other stakeholders in the QA process once you’ve done enough QA of your own to ensure the app works at least 90% of the time.  Call it a focus group, call it User Acceptance Testing, call it whatever you like, but make sure the rest of the team has the chance to use and approve the system.

5.       Have stakeholders from other business units’ sign-off on the test plans that will be used to QA the new feature.  This gives them skin in the game and helps ensure they will engage fully enough to ensure what their attesting to is accurate.

6.       Educate.  Unless you’ve done that and been there you may not be equipped to understand what is involved in high quality software development.  Work with other stakeholders so that they get the value of the exercises you’ll be putting them through as you create screen prototypes, functional specifications, etc.  Knowledge is power.  If you find your stakeholders lacking the product development experience necessary to get the job done do your best to bring them along.

Two brains are better than one and four brains are better than two and eight brains are better than four.  Geeks (and I mean that in the nicest way) shouldn’t be deciding what software does, they should be deciding how it does it.  Let your business stakeholders determine how a new feature should look, feel, behave.  They are generally the business experts.  Using them to design the product will yield the best product possible.  If a gap exists in the engagement of that group do whatever you can to bridge it.  You’ll be better off and (much) more importantly your users will be far better off.  Good software is collaboration between all aspects of a business.