Requirements: Not Just for Application Projects
70% of projects that fail are due to poor requirements, no matter what kind of IT project it is. Applying a reasonable requirements discipline often faces more resistance than with business automation projects. Why do we doubt ourselves?
Talk about requirements and most people jump to the requirements work done for business application projects. But what about internal IT improvement projects or infrastructure projects? Applying a reasonable and light requirements discipline inside IT often faces more resistance than with business automation projects.
Let’s take a look at the high-level types of requirements that impact business application projects, see how they map to internal IT projects, and address common concerns or resistance that surface for internal IT projects.
This is what people think of most commonly when they think of requirements work, and they think of it normally in terms of business function automation:
- We understand the part of the business function we are automating and the specific needs, features, data, rules, etc. that must be part of the solution.
- We elicit and prioritize those requirements and use them to assess, compare, and configure a purchased package, build a custom solution or some combination.
- We use those same requirements to test whether we solved the part of the business problem that the automation was meant to solve.
How does this map to internal IT projects?
- Whether the automation is a new testing tool, a new governance application, or a new telephony application for the service desk, the automation is meant to automate some part of the IT business function.
- Just as with business applications, we need to know what part of the function or process we are automating and we need to know what features need to be part of the automated solution.
- We need to elicit and prioritize those requirements to help us assess, compare, and configure purchased tools, build a custom solution, or some combination.
- And we need to test that we have met our needs.
Now let’s look at the resistance points and how to address them.
Resistance point: “We already have several tools from this vendor so we are just going with their tool. It makes sense from a support and license perspective.”
I won’t debate the pros and cons of due diligence and whether the decision to pick a tool for this reason is good or bad. The decision simply does not eliminate the need for requirements work.
- You still need to configure the solution to best match your needs within the configuration options available. Making up configurations on the fly is inefficient and difficult to test so you need enough requirements to make the right choices.
- You need to have enough requirements understood to be clear on what the chosen tool or application does not do. If the need is not solved by the automation component of the total solution, it still must to solved somehow, usually through manual work and process. Requirements provide the gap analysis.
Resistance point: “We aren’t doing requirements. I know this tool from another place I worked,” or “I have a relationship with this vendor and I trust that they will solve our need.”
This is really just a variant of the point above. The tool still needs to be configured. So enough requirements have to be completed to do the assessment and execute the configuration.
What was known from a previous deployment is useful but it makes the very risky assumption that the current organization’s needs are identical to the past organization’s needs.
Trust in a vendor is a wonderful thing, especially when backed up with real experience, but if the vendor is executing the configurations they still need to know what you need. The two likely scenarios are:
- The vendor bakes requirements work into their installation costs to you. This can certainly work but is not “We aren’t doing requirements.” You are, and you are paying for them to be done. The question becomes: How much control of or visibility into the requirements work do you want?
- The installation takes longer and is ineffective as the vendor does not apply enough discipline to requirements work. You may face added costs through vendor change controls to the installation project and/or a strained relationship with the vendor, hurting the trust you went in with.
Resistance Point: “Requirements take too long. We are just going to get the tool in here and start playing with it. Our people know what they need and they’ll figure it all out.”
Well, it is true that requirements do take some time and time comes with cost. But then so does playing with the tool and figuring it out! Here are some key questions to ask when deciding on the requirements vs. play approach:
- What will you do if team members do not agree on how the tool should be configured? How will you decide who has the best approach and whether that approach is mapped back to one of the goals you had for bringing in the tool or application?
- How will you know if someone playing with the tool is spending time on configuration options that are low priority?
- How will you know when the playing is done?
- How will you test that all needs have been met?
Training, Skills, and Process Requirements
Requirements do not end with automation. When done well, business application projects also include requirements that are not related directly to building or buying of a specific business function. This is where we determine if the automation requires people to learn new skills. Will they require training to use the new application?
Does the automation is change to the business process? Does it require people to learn some new business skills? Do they need training on the new business rules or approaches? We need to understand if the project requires changes to job descriptions and/or people performance management.
How does this map to internal IT projects?
Whether the project is about a new systems management tool, a new development environment, or a new time tracking system, the users of the tool will very likely require training on the tool. Some people will be casual users or users of reports; others will need to operate the tool. All the categories of users must be determined and their training requirements identified.
Will the project require a change to the development methodology or service management processes? Or an addition of new templates or deliverables (such as Service Level Agreements (SLAs) or testing plans) as part of the person’s work? What education do people need to be effective?
Is this project changing roles or altering performance management requirements? Some examples:
- The use of automated test tools needs to be added to the job description for testers. There is a level of expertise required at each job level to be considered as a good performer.
- Understanding of ITIL concepts must be added to the job descriptions of the help desk supervisors.
- Use of automated governance tools must be added to the job description for compliance analysts.
- The new systems management tool raises the performance bar for detection of system issues.
The biggest issue with internal IT projects is that these kinds of requirements aren’t even addressed. The issue is not so much resistance as existence! Once raised, the following resistance points typically follow.
Resistance point: “The online tutorial is there; that’s all the training IT people need”, or “They’ll play around in the tool until they figure it out.”
In fact, both of those options may meet all or part of the training and skill requirements. The problem is the immediate assumption that these are sufficient. Here are some questions to help break or validate the assumption:
- How complex is the tool? Does the tutorial cover any advanced features you need?
- How much time will the project allocate to let people “play around” in the tool? How will you know if they’ve learned what they need to know?
- Are there several ways of doing something, and if so do you need it done consistently? Does this change the kind of training needed?
- What happens when new people join the team? How will they be trained on the tool?
Resistance point: “We’re not going to spend any time defining processes or procedures. They know how to do their jobs and they’ll figure out what has to be changed from whatever they do today.”
As above, depending on the situation this may be a fine attitude. And again, the issue is about the assumption that there is nothing more needed. These questions can help challenge or validate the assumption:
- What happens when there is a new member of the team? How can new team members learn what the process or procedures? How much time will it take to bring a new person up to speed?
- Do audit, regulatory, or other reasons require the process or procedure has to be done consistently? What could happen if the process or procedures are not done consistently?
- How quickly does the new solution (combined process and automation) to be running effectively? How much time is allocated on the project for its practitioners to figure it out?
- Does this team coordinate with another team that needs to understand how this team works?
Let’s Stop Doubting Ourselves
Generally, resistance to requirements on internal IT projects has its roots in just how hard it is to get time and money for any internal IT improvement projects. Everyone wants to make that hard-earned time and money go as far as possible and it is natural to look for activities to cut out. On top of all the reasons above, we need to remember that we apply requirements disciplines to business application projects in order to:
- Reduce the risk of not solving a business problem or leveraging a business opportunity.
- Contain the scope of the solution to those requirements that map to business goals.
- Provide further opportunity for scope decisions by having prioritized requirements.
- Ensure that people needs, process needs and automation needs are integrated as a holistic solution.
We need all of that for internal IT projects as well. According to several studies including the 2009 Business Analysis Benchmark from IAG Consulting, seventy percent of projects that fail are due to poor requirements, no matter what kind of IT project it is. We have an obligation to manage the risk of internal projects taking more time or more dollars or not reaping the efficiency benefits, and good requirements practices help us do that. We can stop doubting ourselves.