Management Technology

Developing and implementing new tools in an organization

In this post, I’m going to expand on my previous posts “Planning for upgrades without disruption” and “Dedicated testing teams” to provide some basic guidance for how to go about building new systems and rolling them out.  This will not be a fully comprehensive guide and you can edit where needed for your organization, but this should serve as a basic outline to help you plan your development and rollout plan.

Plan it out

Once you have decided that it is time to build a new tool you must first lay out your requirements for the tool.  Once you have your requirements you need to judge them against your resources and determine if you have all that you need or if you need to bring in new resources.  During this time it is important to include the development team for the project, they will have the best knowledge of what will be needed.

Gather your data

Now that you are ready to begin building the new tool have the development team sit with the people actually using the current tool to get a feel for how they use it.  After the observation time is done have the development team interview the users of the tool to find out what they like and dislike about the tool.  Once all the data for the current tool has been gathered present the plan for the new tool to the current users and ask for feedback.

Note: Do not skip this previous step, it is important for the developers to understand the needs of users to be able to build a tool they can use.  Asking a developer to build a tool without knowing how it will be used would be like asking a blind man to paint a Picasso without having ever been able to see any of his paintings.

Iterate based on data

Now the development team needs to take all the data that has been gathered and develop a second proposal for the new tool.  This second proposal should take into account all the data gathered from the data-gathering session with the current users.

Present the new proposal to all stakeholders and gather feedback from them to decide what can and can not be built.  At this point, the development team should be leading this change as they are ultimately responsible for the end product.  The development team should then take the data from the users and the data from the stakeholders and decide what is possible, then write a third and final proposal and present it to stakeholders and users for feedback.

If one of the parties decides the final proposal will not work then the development team should work to find a new alternative.  If on the other hand, there is no major objection then the development team should work with leadership and other stakeholders to develop a budget and timetable for building, testing, and rollout of the new tool.  I would like to clarify what a major objection is, a major objection would be something along the line of  “this will cut productivity in half”, this will not integrate with outside systems we have to use” ect.  Minor objections such as “the font is difficult to read” should be addressed but should not serve as a reason to cancel the project.

Build an MVP

Now that the development plan is finalized, and has a budget and timetable it’s time to let the development team get to work.  All other tasks should be handled by other supporting teams, the development should not be handling I.T. related issues while working on the new tool.

Once a minimal viable product has been produced stakeholders should have a chance to preview the tool and provide feedback.  The development team will then take that feedback and continue building the tool to prepare it for alpha testing.

Alpha testing

Once the tool is ready for alpha testing a small group of testers should be selected from the users of the current tool.  They should be told to report any errors they find, and provide any feedback they feel would help improve the tool.  Alpha testers should be told that criticism is fine, but that it should be constructive criticism only.  During this time the development team should work to fix the errors found by the alpha testing team and improve the tool based on ideas and constructive criticism from the alpha testers.

Beta testing

Now that the alpha testing phase has been completed the beta testing phase can begin.  The beta testing phase should include all users of the current tool.  Time each work day should be allotted for testing.  At this point, testing should not be a full work day, only test for a limited time and allow testers to return to using the current tool to ensure they are able to complete their work.

Full lock-in

Once the development team has stopped revising error reports from testers for a predetermined amount of time a “full beta test testing lock-in” should begin where testers are required to use the new tool for their entire shift.  It is important to keep the current tool active as a fallback but limit its use to management approval.  If management approves the use of the current tool a report to the development team must be written detailing the reason for the fallback.  Once the issue that caused the fallback has been fixed, have the users return to full beta test testing lock-in and continue the testing until a predetermined amount of time has passed with no new issues reported.

Put it into production

At this point, the current tool will become the legacy tool and the new tool will be the current tool and will be taken out of beta testing and put into full production.  It is important to keep the legacy tool active at this point as issues may arise that had not had a chance to occur during alpha and beta testing.  I would recommend and end of life date of 6 months after the end of beta testing.

Congratulations, you’ve successfully built your new tool with minimal disruption to your organization.

Summary checklist

  • Layout your requirements for the tool.
  • Decide what resources you have and where you can get more if needed.
  • Have the development team sit and observe the users of the current tool.
  • Gather feedback on current tool from users.
  • Present proposed new tool to users and gather feedback.
  • Build a second proposal based on user feedback and present it to stakeholders.
  • Gather feedback from stakeholders.
  • Build a third proposal combining all feedback.
  • Decide if the project will continue based on the third proposal.
  • The development team builds minimal viable product for stakeholder feedback.
  • Test the tool with a limited number of current users in alpha testing.
  • Collect feedback from testers and fix errors.
  • Begin beta testing with all users on a limited-time basis.
  • Collect feedback from testers and fix errors.
  • full beta test testing lock-in.
  • Collect feedback from testers and fix errors.
  • Put the new tool into full production and put the current tool in legacy mode for 6 months.

Conclusion

While this may seem cumbersome it will ensure minimal disruption to your operations and ensure better buy-in for your staff because they will have the ability to provide input through the entire process.  Is this process more time-consuming and cumbersome than just building a tool and telling users to use it?  Yes of course, but it will be less costly than having your staff’s productivity cut in half because the tool was built without any knowledge of what is needed.

While following this method of development will be more time-consuming and costly, it will be less time costly than having productivity slowdowns and not being able to deliver your product to your consumers.  It’s better to invest upfront than risk having to invest more later to fix issues and support two systems for a longer time.

Like what you see?

Sign up to receive new posts in your inbox, every month.

I do not spam! Read my privacy policy for more info.