Assess Organization Readiness
Have you ever been handed a new solution without any idea or knowledge of the solution and why it was being implemented? I’m talking about you as an end user of the solution and not the business analyst. Chances are you didn’t use it. You definitely didn’t use it as effectively as you could have. The business analyst has a role in making sure that the organization and the users are ready for the solution and will use it effectively, before the solution is implemented. This is something that should be happening throughout the project as part of defining the transition requirements to support the project. An assessment of the organizational readiness needs to be conducted prior to rollout of the solution in order to get the benefit expected from the project. This is an opportunity to understand the additional steps that are needed to sell the solution across the organization or to prepare the users for its use.
I once worked on a project to implement a new time keeping system to record staff time to projects. The value in the solution was going to be in getting good metrics on how staff spent their time and on which projects, in order to understand the cost of projects compared with maintenance activities. I had identified that it was going to be a hard sell to convince staff to record their time at the level of detail needed to realize the benefit expected. I had begun to arrange for the project sponsor to visit each of the different working groups so that she could promote her vision for the solution and how it would make our lives easier in the long run. She did not feel this was a necessary step. I attempted to explain that in order to get data into the system needed in order to get the reports out of the system that she wanted, it would take additional convincing on her part. Her response was that since she was the CIO, that was all of the convincing they needed. After the project was implemented, only about 50 percent of staff were actually recording their time in the new solution, and a very small percentage of the reporting was at the granular level of data needed to get useful information from the system. We spent a lot of time after the time system rollout trying to get staff to put their time in the system at the level requested. We were faced with strong resistance and the data coming out of the system was of little use. A little effort, and selling of the solution and benefits to the organization and the staff will go a long way toward allowing this solution to bring expected value to the organization.
This is just one example of why we need to understand how ready the organization is for the solution and, more importantly, what else the project needs to do to make the solution viable and valuable. It may mean in some cases that the business analyst recommends delaying implementation in order to satisfy some additional transition requirements needed in order for the solution to achieve the value expected.
In many cases a lack of organizational readiness may not be a barrier to implementing the solution. In this case the business analyst will have to identify what needs to happen for that implementation to ultimately be successful. This may include doing informational sessions with users, producing additional user documentation, or identifying blocks to the solution use that will serve as a basis for a future enhancement. What will it take for the implementation of the Requirements Management Tool solution?
It was getting closer to the time that the new requirements management tool would be released. Liz wanted to do a final touch base with business analysts in the organization to make sure that they would be ready, willing, and able to use the system. She dropped in on a couple of business analysts to strike up a conversation and ask how they felt about the upcoming solution. She could tell that they were optimistic about the value that the system would bring, but also apprehensive that it was going to be difficult to learn to use in order to get the most out of the system. She determined that she would get a better understanding of how easy the system would be to use as part of user acceptance tests that were soon to come. She decided that she needed to put a little more effort into preparing for the user acceptance tests in providing direction for the users. She wanted to use the user acceptance tests to determine the users’ readiness for the system, but also to understand what additional needs the users had from the project in order to be successful in their use of the system. She wanted to get a feel for how much additional training or user documentation it would take for the business analysts to be effective in using the tool.
Liz shared her thoughts regarding user acceptance tests with Mary and Matthew as a heads up that there may be additional work on her part in order for the use of the system to bring the benefit expected. She told them that she would know more after user acceptance tests and would keep them informed. She further let them know that there would be no reason to delay release of the system, just there may be more work to get users to use the system as effectively.
Validate the Solution
The solution to be implemented requires validation to ensure that the solution indeed meets the requirements and can achieve the business results expected. There are two important aspects of this validation.
The first is identifying the gaps in the requirements to the completed solution. Often, these gaps will present themselves as defects in the solution. The business analyst, in this case, will need to determine whether the defects are a true block to implementing the solution or whether there are workarounds available that may work in the short term. The first step is to review the defects found and then determine the criticality to solution implementation. The business analyst should look at the likelihood that a defect will be encountered by a user and also the impact it will have on them completing their work. A text field that has fewer characters available than desired may not be a factor. It may be an inconvenience, but it should not delay the implementation of the solution.
On the other hand, lack of system availability may be a true block to implementing the solution. Healthcare.gov21 was one example of a solution that was not ready for implementation. This is an example where a desire to meet a release date overrode the need to provide value to its users. This project ultimately was an embarrassment to the U.S. Government, and they have spent months trying to correct for it.
I recently had a conversation with a student who was concerned that releasing the solution with bugs was always going to make the organization look bad. In reality, there will never be a solution implemented that is entirely free of defects. There needs to be a careful evaluation of the defects that are known in the actual impact to the users. For known defects it becomes important that the business analyst and the project team are candid about the facts known and how they are going to be addressed. The other important validation that needs to happen is to understand the benefit that the solution will provide in regard to the expected outcomes to the organization. This often happens by conducting user acceptance testing. The business analyst is the lead in coordinating this testing effort; however, they are not the “user”. This includes identifying members of the user community who will test the system, the level of formality that will be used in order to conduct the test, and the scenarios or scripts used for testing. User acceptance testing provides a way to get real user feedback on the solution prior to its implementation.
Ultimately, it will be up to the business analyst to inform the project manager, the project sponsor, and the project team that the system is ready for use and that it will bring value to the organization. If the system is not ready for implementation, then the business analyst will need to identify what the barriers are and recommend solutions to those barriers. Users often will not remember if the system was implemented on time or not; however, they will remember if it was a poor quality system once they touched it.
Liz had been working closely with the testing team, and felt she had a good understanding of the defects of the system. She knew which of the items were determined to be addressed by the project team before the system was released. But there were also a handful of defects that would not be addressed. These were a few that she felt would be unlikely to be experienced or noticed by users, and that if they did experience the default, they would not stop users from doing their work. None of the known defects would be a big deal. She did want to be candid about the defects she knew of, so she created the list and used this in communicating with the users of the system as well as Matthew, the project sponsor.
She had arranged users to do user acceptance testing on the system prior to its implementation. To prepare for the user acceptance test, she created some user documentation that would help the folks navigate through the system. The user documentation along with the defect list would be covered with the user acceptance testers in their session. She started the session by providing a high-level overview of the system scope and what tasks they would be able to complete using the system. She then had them focus on the defect list and walk through each defect in order to help set the stage for how likely it would be that they would run across the defect and what the impact would be on their work if they did. She asked questions along the way in order to validate her assumption on the likelihood and impact of each defect. In one case, she upgraded a defect to critical based on feedback from the acceptance test team. She would talk to Mary and the project team about addressing this issue prior to rolling out the system.
She provided each of the testers the script for their user acceptance test. This script provided a high-level walkthrough on the tasks she wanted them to complete along with general guidance on how to complete them. She also provided them with the user documentation that had been created for the system, and suggested that they refer to this as needed as a means to also test the usefulness of the documentation. Liz and several team members were on hand for the user acceptance tests so that they could observe how the users there had been using the system, answer any questions the user acceptance testers had, and also record observations for the project team.
To conclude the session, Liz led a discussion from the users on their impressions of the readiness of the system. The overall consensus was that the system was ready to be installed, but a little more work would be needed to prepare users through education. The recommendation was to create a series of brown bag lunches to cover system features as this would go a long way toward helping them use the system effectively.
Liz was thrilled to report to Matthew and Mary that they could roll out the system on the released planned dates. She also mentioned that she would need to spend some time with users with the brown bag lunches to help them transition to using this new product.
Get Solution Sign-off
Ready, Set, Go!
The business analyst will use the information found through validating the solution to make a recommendation to the project sponsor on whether the solution is ready to implement. They should be prepared to present their findings on the facts and barriers of organizational readiness along with any recommendations they have in order to make implementation and the project successful. These items may be treated as change requests that would be subject to formal change control. The decision on whether to implement the project or not is ultimately up to the project sponsor based on the facts and findings of the business analyst and the project manager. It is in the best interest of the project and the organization to be a squeaky wheel and make sure the sponsor understands the risks involved if you do not feel the organization is ready. No one ever got fired for arguing in favor of something that was in the best interest of the organization—at least not fired by reasonable people.
Liz, Mary, and Matthew met to discuss the system go-live date. They talked about the findings from Liz and the project team about the user acceptance and the need for additional training. They discussed the outstanding defects and agreed that there would be in maintenance and enhancement release within the next year so that these could be addressed. The recommended additional training would not impact the rollout of the solution. Mary and Liz recommended, and Matthew accepted, that the solution was ready for release.
Your Assessment
For the selected project …
1. Was there an effort to determine the readiness of the organization, staff, and users for the new solution?
2. Was adequate testing conducted against the solution to understand system performance and defects prior to rollout?
3. What factors were considered to determine the final rollout date of the solution?
4. Were there any barriers to end users in using the system once deployed? If yes, how were these addressed?
21When healthcare.gov was implemented, thousands of users were not able to use the system because of system outages and overloads. It was several months later before the U.S. Federal government resolved these issues. See http://www.theverge.com/2013/10/20/4859316/healthcare-gov-woes for more information.