Zopim Chat

Rodney Brim Report

The Rodney Brim Blog

Avoid Starting Out on the Wrong Foot in Software Deployment

July 22, 2008
manageprouser

There is a Correct Sequence for Software Roll-out or Deployment… Ignore at your own risk.

Sequence is important in lots of areas of life, and each time it tends to bring order and efficiency to potential chaos.  The Ready, Aim, Fire sequence is a familiar one, which if followed out of sequence, tends to produce misguided effort and induce more chaos, expense and frustration.  Any kid on a baseball diamond this summer can immediately tell if you should choose to run the bases out of sequence, and if near-by will either yell at you or think you’re weird if you do so. 

Just like baseball, there’s an important sequence to rolling out software, especially when it is software that will extend across multiple people and impact existing processes (Project management, performance management, balance scorecard and collaboration software are all good examples).  Here’s the correct sequence with examples, then let’s explore it briefly.

Software Rollout Sequence:

1.  Establish the Goal or targeted Outcome – specifically those goals or standards for which an organization is willing to hold people accountable to reach on a regular basis.

Example – We’re going to coordinate our work effort better and as a consequence reduce out project over-runs by 15% and improve the % of Due Dates we achieve by 35%, all while spending 50% less time in meetings). 

2. Identify what changes need to occur in behaviors to reach the targeted outcome, both the new behaviors required, and the old ones that have to be abandoned.  

Example – We’re going to manage all projects and tasks that effect multiple people from a central collaborative workspace with clear planning and assignments, and up-to-date information to enable us to achieve our coordination, budget and timeline goals.  We’re going to communcate project related information in a timeline specific and brief manner.  We’re going to use progress updates and todos or task requests, not email narratives when managing projects.  We are no longer going to use whatever we personally prefer as a project management tool  (ex. Note pads, email folders, spreadsheets, because yes we all have different preferences) when managing group projects, we are going to use one common tool, so as to sing off the same song book.  Finally, we are no longer going to substitute attending long meetings for regular write-ups of updates on projects. 

Hint:  You’ll have the most success if you think of the required behavior changes as rungs on a ladder, moving from simple (I can do myself) to complex (I can only do with inputs from other systems).  Make sure you have all the rungs on the ladder before you have people begin the climb.

3.  Roll-out and establish competency and comfort with the new technology – Apply the technology and training in its use to a succession of steps that need to take place to move users from current processes and practices to the new practices that will ensure target or goal outcome in such a way that users build competency and comfort.         

Example – The first step might simply mean adopting a common naming convention for projects, a common way of defining the structure and location of projects, how to navigate to the project and view what assignments are due for each user.  You would want to start the technology training at that behavior run, not at showing them how to compute estimated versus actual due dates and the relative extension of duration as a % of the entire duration.   

Hint:  Most people only climb ladders one step at a time, and in a similar fashion, most people learn new technology by building on one new skill at another, not by aborbing lots of new concepts, key strokes and capabilities at once. 

Bottom Line:  First of all, at the 30,000 foot level, there is a correct 1-2-3 step sequence to rolling out software.  In any role out, the new technology needs to support the change in behavior or process, not vice versa.  And the change in behavior or process, being clearly defined as needing to support goals for which the organization is willing to hold people accountable to reach on a regular basis.  The correct sequence again is:
1.  Establish the specific goal or target (addresses one or more pain points)
2.  Establish what new behaviors and practices have to be adopted, which ones have to be abandoned
3.  Then introduce the software technology to support the new process and ultimately the goal.
You can imagine, and have probably lived through, software roll-outs that were conducted out of sequence.   They don’t do so well.  Obviously, starting with a search for the “right” software is not the first step, even though it’s one that’s commonly adopted, e.g. doing the sequence in reverse order has no positive benefits that we’ve been able to determine.  By-the-way, there is some benefit to strategizing about what you decide to target in the behavior and process change sequence.  I’ll address that in the next blog. 

Links:

First of Two Key Questions that Predict Success at Deploying Software

Software Adoption; New Wine in Old Wine Bags

Finding the Pain before you Implement a Software Solution


1 Comment. Leave new

This blog is very useful. Can’t tell you the times when choosing the software prior to identifying the objectives we need to overcome as a company generally comes after the selection of the software. Only to find out that the software does not meet the needs.

By identifying needs first, software second, helps us to ensure a good fit, think through the business problems we need to conquer and to do this successfully, we find that collaborating across all business units is a must. If not, we find major gaps in our plan to improve and achieve our plans. Once we have all the input it becomes less of a thought process to identify how the organization will use the software to overcome our pain points. The implementation becomes less complicated and our objectives are clear, everyone knows what their role is, we have a better idea of the metrics we need to measure for success, and we move forward with direction that makes sense and maps to our plan. I find the investment immediately becomes worth the time and effort.

Having these important pieces to the puzzle figured out beforehand then serves as requirements for applicable consulting engagement, software configuration and training objectives.

Thanks for this valuable information!

Reply

Leave a Reply

Your email address will not be published. Required fields are marked *