Requirements in Supplier Selection Projects

If you know ahead of time that the software is going to be purchased instead of built, how does the requirements process differ from that of a standard development project?

I think a key difference in a supplier selection project comes from the fact that you are buying functionality that already exists. And while you will probably customize and configure the software, it is not necessarily going to be exactly the same end result as if you developed it internally.

Given that difference, it makes sense to gather high-level requirements and select the supplier using that level of detail. Then work with the supplier to specify the detailed requirements necessary to configure and implement the supplier solution, integrate it to existing systems and custom build any missing functionality.

Inherently, you will be forced to really focus on the core requirements and leave design out of the picture while you choose the supplier. Once you have selected a supplier, you will find it very challenging to speak about requirements without talking about the design of the solution you selected.

As you compare supplier software, you will probably have to make some tough decisions. For example let’s say you have 4 features. One supplier may support features 1 through 3. Another supplier supports features 2 through 4. A decision maker on the project has to weigh all of the factors to make a choice including things like: price to buy and implement each solution, price to build the missing feature in each case, cost of not having one of the features, time to implement. But the reality of this situation is that someone may decide that feature 4 wasn’t really a requirement after all!

A proposed approach to selecting a supplier
For the actual requirements process, here is an idea of what we follow to select a supplier:

1. Define the actors that will use the functionality.
2. Define the high-level requirements. This may take the form of named use cases or features.
3. Specify more detailed requirements based on the highest risk areas.
4. Research the marketplace to identify a list of potential suppliers. This can be done by surveying SMEs, doing web research or talking with colleagues.
5. Narrow the list of suppliers down to the top three to five, based on how closely they match the requirements gathered.
6. Have the suppliers do high-level demos of the solution. Eliminate any suppliers that do not seem to be a fit at this point.
7. Create test cases using the requirements gathered to sufficiently demonstrate how each supplier measures against the requirements.
8. Have the suppliers demonstrate how their solution satisfies the detailed requirements, measured by execution of the test cases.
9. Create a comparison matrix with each test case (and all other measurement criteria you care about) to directly compare the suppliers.
10. Gather information from the supplier, beyond just the functional capabilities.

• Gather pricing data – licenses, support, installation, training, etc.
• Ensure the supplier’s business operations are acceptable
• Determine if their support structure is acceptable
• Understand what their development roadmap looks like
• Perform reference checks with colleague
  

11. Decision maker chooses a supplier.

Once a supplier is selected, the detailed requirements gathering process should continue. Your detailed requirements should be focused on the scope dictated by the supplier you selected. In standard development projects you would expect to go into more detail on most areas of the system, to ensure you understood the requirements to build a complete solution. In supplier selection projects, there will likely be pieces of functionality that they demonstrate to you, and based on the high-level requirements and risk, you realize that their solution is sufficient and do not need to explore it further.

However, if there is an area in which there is a lot of flexibility in the supplier solution, you should specify that in more detail. Obviously If there is a gap between critical requirements and the solution the supplier provides, you should go into greater depth on those requirements. Points of integration should be explored in detail. Also, it is worth noting that typically you will also spend more time on updating existing processes to work with the supplier solution, whereas in standard software development you may build software that fits into existing processes.

At a low level, you can still follow the same requirements techniques on supplier selection projects. However, realistically your approach to the requirements process should be very different to ensure you select a good software solution and that you minimize throwaway work.

How Communication Styles Affect Requirements Sign-Off

I’ve recently had some troubles getting all team members to provide approval for a requirements document. I know the reluctance is a sense of not knowing what the requirements contain. I thought maybe if I could tailor how I disseminated the information to different communication styles, I could receive feedback in a more complete and timely manner.

I turned to the internet for inspiration. I started researching communication styles. I expected to come up with visual, auditory, etc. I found this type of information but something much more fascinating came up. Since the time of Hippocrates it has been generally accepted that there are four communication styles. Carl Jung extended the meaning of the four, refined them slightly, but basically agreed there are just four. Even today we see professional business trainers use four basic communication styles when training how to communicate more effectively in business.

The names I find most appealing are: Expresser, Driver, Relater, and Analyzer. The Expresser tends to get visibly and externally excited about ideas and discussions, be impatient with lengthy explanations, strive for recognition, and make quick decisions as long as the idea being decided is exciting. However, the Expresser’s enthusiasm can often be mistaken for buy-in. The Driver tends to take charge and focus on results, finds it annoying to have someone else make a decision for them, strives to win, and also makes quick decisions but given time will tend towards a “no” answer. The Relater pays attention to how everyone else is reacting to the situation, worries about disappointing others or not meeting expectations, strives to build consensus to keep everyone happy, and needs time to make a decision. The Analyzer asks a lot of specific data driven questions, hates to make a mistake, will check and re-check calculations to make sure solutions are sounds, strives to complete the necessary steps to find a thorough solution, and likes to review all considerations before making a final decision.

I’ve summarized mountains of information to a few short sentences. The relevant piece of each communication style is how that person likes to make decisions. Expressers and Drivers make their decisions quickly. They are impatient and hate spending a lot of time embroiled in details and muckity muck that makes a quick decision less practical. Given time, the Driver will tend more and more towards a “no” decision.

In an environment where a Product Manager is seeking approval for a set of requirements with an Expresser and/or a Driver, it may be best to summarize the meat of the requirements in as concise a presentation format as possible. Then follow up by calling the Driver or Expresser and talking them through the information until a decision is reached relatively quickly. Simply sending out a large document and giving this type of communicator time to review it will not be effective. These communicators want information distilled to the relevant pieces so they can make an evaluation and decision quickly. Another facilitation method may be to host a meeting between the Expresser and/or Driver and yourself. As long as the meeting focuses on areas of consensus and does not get bogged down in how to change areas of contention, it should be relatively easy to get an Expresser or Driver to agree on the areas of consensus.

Analyzers and Relaters needs more time. They like to evaluate all the information available to them, determine how others might feel about the information, and evaluate whether the information is the “right” and “correct” information. These communication styles require a different approach. When trying to get approval from an Analyzer or Relater, it’s probably a good idea to send them the document and then schedule a follow up two or three days later. This gives the party time to read the document, evaluate the document, and come to a decision.

It’s possible the Relater will need to make the decision as part of a group. This communication style is reluctant to make decisions without measuring the concerns of the other parties involved. You may want to schedule a group meeting where the Relater can see others approve of different aspects of the document. If the relater is willing, you may ask him/her to identify areas of concern and then find others who approved those areas and let the Relater know of the additional support.

It’s possible the Analyzer will need more data. You may ask him/her to provide areas of contention and then seek out data to support one path versus another. You may need to quantify other feedback and approaches to get Analyzer buy-in. In any case, your Analyzers and your Relaters may need more time to review documentation. Your Expressers and your Drivers may need more attention to review documentation.

Armed with these four different communication styles, on any project, it should be easier to find a way to elicit a response from a particularly quiet team member. Good Luck!

One Owner

On every project in the software world there are numerous owners responsible for the success of the project and whether the business objectives are met at the end. Some companies has some embraced the idea of group ownership that they forgotten the value of accountability and hierarchy and, as a result, encounter problems completing projects. Although the concept of shared ownership might be nice, the reality of it is rather treacherous. The ideal in a shared ownership world is everyone working together on a common goal towards making a project successful. Each owner contributes his or her “fair share” to the project to make it a success.

We all remember high-school group projects. Shared ownership only works with very small teams where everyone on the team knows each other well and has a personal interest in seeing the other members of the team succeed. For example, if the team members are family or very close friends shared ownership might work. However, even in these situations shared ownership can lead to bitter fights, broken families, and ended friendships. Shared ownership fosters failed projects and finger pointing.

The truth of the matter is: we all work at a different pace, with different ways for accomplishing the same tasks. In a project with multiple owners, there is always someone who wants to move faster and push harder than the team as a whole. There is also always someone who wants to slow down and understand everything before taking the next step. Neither approach is bad. Both approaches have merit. However, when a project has shared ownership the two approaches can conflict and create tension within the group.

In many situations the tension can be healthy. It can force the fast driving pushers to consider their approach to make sure loose ends are tied off. It can force the slow methodical plodders to prioritize and make decisions about which aspects of the project are more important and need attention first. The problem comes when there’s a loose end that no one ties off or a decision that never gets made. These situations create a stalement between the plodders who are unwilling to make a decision and the pushers who are ready to make a rash decision as long as a decision is made. This situation screams for a single owner.

When a project has a single owner, there is one person to decide when consensus cannot be reached. As much as we would all love to have consensus on every decision, it is not always possible. We can drive towards it and drive towards it and eventually someone needs to draw a line in the same and state “this is how it’s going to be”. Corporate America recognizes this need for someone to have final authority. It’s why we have terms like “escalate” and “boss”. Someone has to make the final decision.

If you see yourself on a project that is struggling to make decisions, determine if it’s a problem of shared ownership. Usually, when decisions cannot be made, and consensus fails, the underlying cause of project churn is lack of a clearly defined owner to force a final decision. Find a single owner. Sometimes the owner is not required to make the decision himself. The owner provides a date by which a decision must be made or a budget to fund a decision. The owner provides the boundaries. Consensus becomes much easier when boundaries are laid out early.

Always find the single owner. If there are multiple owners, spend the time to establish the single owner. Escalate to establish the single owner. Every project, decision, direction needs a single owner to follow it through to completion.

Requirements for the Easter Bunny

When I was a teenager, I cut grass for the Tooth Fairy. Quite frankly, she was unpleasant to work for, and she was very slow to pay. I resolved to never work for anthropomorphic representations of mythological creatures again.

To my dismay, I found myself rolling off a project a few months ago, and I got my next assignment.

Helping to document IT requirements for the Easter Bunny.

This was something of a surprise to me. I generally don't associate "Easter Bunny" with IT. I normally think about colored eggs and woven baskets.

In reality, the Easter Bunny (EB) runs a complex operation with some fascinating and competing business needs that translate to IT requirements. EB needs to interface with major egg distribution networks, and to be able to coordinate deliver to his Indonesian egg painting factories. His accounting system is messy, since he's apparently paid using covert funds from the CIA. He operates in nearly every time zone, and has a major peak in IT requirements every Spring.

I was brought in to do requirements associated with the next release of the Egg Paint Inventory Control System (EPICS). The problem with EPICS was that EPICS had evolved slowly over a period of years. As an IT system, it was basically a collection of components that had been taped together and had many bandages applied. Generally, when I write requirements associated with a new release of a system, I write it as a delta from the existing system. In fact, this was the model that the EB's IT team had used in the past. The problem was that the original system was never documented, because at the time it was considered to be a relatively simple application that would be going away soon. Unfortunately, the business added a bunch of functionality in the early versions, and EPICS became inextricably linked to the other IT systems. Historically, updates to EPICS didn't go well. Users often reported that updates would add new features, but break old ones. This was clearly a case where writing the requirements as a delta to the existing system was going to be very risky. We needed to document the full system, and then write the changes as a delta.

This was an interesting exercise for me, since I generally write requirements documents in the form of an SRS or BRD. Should I write the documentation for the existing system like a requirements document?

I had to step back and think about the requirements for my document.
1. The current users of the EPICS system needed to be able to review the document for accuracy.
2. There would be elements of design in this document, since it was describing what had actually been done.
3. There needs to be a way to reference sections of the document at a high level of granularity, so that the "delta" documents are able to reference which sections are changing.

The document that I ultimately produced was centered around Use Cases, but with more details of the system interaction than I might normally use when producing a requirements document. Steps taken by the System tended to be more explicit. For example, rather than "System checks red paint levels", we'd write "System sends a signal to the troll guarding the paint. The troll measures the level of red paint remaining, and signals the elves manning the EPICS system." Lots of design built into that statement, but it helps us to understand what it is that the system is currently doing. Each of the use cases was numbered so that it would be easy to reference them in delta documents. For portions of the document that weren't use cases, we carefully numbered each paragraph.

Once the system was documented, the delta was actually fairly easy to write.

This project reminded me why I like working as a requirements analyst so much. I get exposure to business processes that I've never thought about before. Six months ago, I would never have connected the Easter Bunny to the Egg Cartels or to Indonesian sweat shops. Now I'm bugging our sales guys to get me a gig at the north pole...

Validation vs. Verification, Part 2

In my last post, I explained the difference between validation and verification. In this post, I'll further explain validation and provide some best practices.

To ensure that requirements validation goes smoothly, the following questions should be posed:

• Are all requirements necessary and sufficient?
• Do lower level detailed requirements meet the objectives of higher level requirements and needs?
• Do the requirements meet stakeholder needs and constraints?
• Are all requirements complete, feasible, and verifiable?
• Which requirements have a large impact on cost, schedule, risk, and/or performance?
• Are all non-functional requirements captured, particularly those that will be important to end users (e.g. performance considerations)?

Validation should be an iterative process - as more detailed requirements are discovered and documented, the questions above should be repeated. As the technical design team gets involved and provides input on the requirements and begins to formulate the technical design, validation should continue to occur (it should be pointed out that technical design also needs to go through a validation process as well).

Consider these best practices when developing requirements:

• Make sure that you have properly identified all stakeholders and their needs
• Ensure that you have properly documented business objectives and required features
• Map each requirement to a business objective/need
• Make sure that you spend sufficient time in eliciting and analyzing non-functional requirements - this should not be left as an afterthought
• Utilize peer reviews to improve the overall quality of your documented requirements

Hopefully this will give you some food for thought to make sure your project "builds the right thing".