An enterprise software project kicks off with much fanfare, and eventually the application rolls out. Management wants to know the usage of the application, and the effectiveness of the application that IT spent considerable efforts building. Finally, when the metrics come in, it’s not good news. Management wants to know answers; business users claim the application doesn’t serve their purpose entirely, not according to spec. IT rebuts there was never a clear spec, or those details were not hashed out as part of requirements. We all (Business as well as IT) experience this situation or different flavors of the same; bottom line is failure in requirements gathering resulting in failed project; loss of credibility, wasted efforts and constant blame game.

Undoubtedly, requirements’ gathering is the most significant of the software development process, but yet, the most unstructured phase. There are impediments from both sides of the isle for this most critical part of software development. Business users say that – the IT guy sits in a corner coding, he doesn’t talk, or he talks too much and doesn’t listen. IT folks claim that business users only show up to project kickoff meetings and complain when the project is delivered that it doesn’t match what they want. If the organization has a PMO office, they could always use the “scope creep” angle to bail out of the situation.

So, who owns requirements gathering for a software project? I always say, IT does! Here is an analogy I like to use. Let’s say we are building a bridge that our business users use to cross the rivers of business problems. We just can’t focus on building the bridge, we need to take into several other business conditions; what kind of load the bridge needs to withstand, what are weather conditions the bridge needs to sustain, the environmental settings of the construction, etc… We just can’t build any bridge, and expect it to sustain all the conditions. So, the onus is on IT. You need to build something, that’s useful, does what it’s supposed to and may be exceeds, and keeps everyone happy.

No business user wants their tools to fail; they are just buried with their operational daily grind. This makes it difficult for them to focus on the problem and get into details. Also, human thought process with respect to serious thinking works in iterations. Don’t expect the business user to describe all the scenarios in one shot, the iterative nature of fleshing out requirements needs to be accommodated. Also, it’s hard for a business user to deliver software requirements in a structured format that IT demands; this could be an unknown territory for them, and IT needs to look for alternatives in this collaboration where the tools and process are less intimidating, fun-filled and one that brings the pleasure of discovery. On the IT side, the usual challenges are lack of business domain knowledge, excitement about technology than the business solution, failure to facilitate a true collaborative process and lack of audit controls between problem and solution.

There are several techniques and practices an IT department can implement to overcome these challenges in owning the requirements gathering, facilitating a collaborative environment with business users and leading to development of great enterprise software solutions. Some of these techniques are traditional, and some radical or unorthodox. But, most of these techniques are informal in nature aligned with human learning and team participation, and yield greater collaborative results.

1. Identify business stakeholders, identify business users that are excited about the software solution, and encourage them to be your solution champions. Internal PR is one big missing piece when it comes to user adoption.
2. Earn the business users’ respect. When they are busy with their daily grind, the only way they spend time with you hashing out details of requirements is when they know that IT guy understands business and when you speak their language.
3. Shadow the business users at their work, observe the intricacies of the business problem, discuss with them what you saw and ways of solving the problem.
4. Agile development is not just for iterative and test-driven models. Extend the agile techniques of collaboration and iterative nature to requirement gathering as well. Involve business users from the beginning, share your perspective of the problem and proposed solution on a periodic basis. Frequent demos to business users during development process enable the feedback loop into design and development process.
5. Pay attention to corporate cultures and subcultures the business users belong to. Often times you find several unrevealed and hidden requirements from these observations.
6. Use tools that are productive and exciting for everyone. I encourage different toolsets for internal (IT use), and external (business collaboration). For internal, you could use UML artifacts, Use Cases to tie the solution to requirements. For use with business users, I encourage the use of Mind Mapping, UI prototypes and mockups. UI prototypes being visual enable the business users to visualize the proposed solution, and experience reveals that user participation rapidly increases with the introduction UI prototypes and mockups. Mind Mapping is another great tool for user collaboration. Mind Mapping takes away the intimidation factor, with its free-flow, and alignment of representation of human thought process, and is a great tool for opening up a problem discussion and dig into details.
7. Arrange frequent demos of the design artifacts, software solution to the users. This makes them feel part of the process from the beginning, and only good things come out of this feedback loop that you build.
8. Create a project Wiki (there are hundreds of Open Source Wiki software solutions available that you can quickly customize and use). Use that as the collaborative platform with your IT and business users, encourage them to participate with their suggestions, feedback, and comments. This gives them visibility into what’s going on in the solution development process, and also helps their need for iterative updates to requirements. You should even consider assigning them action items on the Wiki; as everyone has access to it and see the outstanding items, their response and action is going to be much swift than through the usual channels.
9. Come up with an IT Solution road map for the solution delivery and clearly define what’s going to be solved in what phase. This helps the users visualize where their specific need fits into the plan, and it’s comforting to see that their needs are not forgotten and they are on the road map.
10. Most IT proposals and user-facing benefit documents discuss in great detail what the software does. I encourage the inclusion of what the software doesn’t do or what the limitations are. This I find is a great way to trigger discussions on ‘what if’ scenarios, and the results can feed into additional detail on existing requirements or a clear scope for a requirement.
11. Arrange for a pre-beta review process and audit the software in terms of adherence to requirements. This will save a great deal of effort and embarrassment for both IT and the stakeholders as opposed to finding things in beta or production with timelines and effectiveness issues pressing.
12. Through out the life cycle of the project, share the success of every milestone with business users. This project may be over soon, but this will help you and accelerate your collaborative efforts with the users on your next project. Also, sharing is nice, isn’t it!

Tags: agile development, business stakeholders, Collaboration, enterprise software, IT road map, iterative requirements, Mind Mapping, Project Life Cycle, requirements gathering, Software limitations, Use Cases

This entry was posted on Thursday, May 1st, 2008 at 11:44 am and is filed under IT Management, Software Development. You can follow any responses to this entry through the RSS 2.0 feed. Responses are currently closed, but you can trackback from your own site.