I recently finished creating the initial version of a process for developing “applications” by people outside of the IT area.  Almost all companies have such development, where an end user develops something that is used in the business, without the assistance of the Information Technology area.  This type of development can be called “shadow IT”, “business as usual”, “end user computing”, dev on the down-low”, but it does have its place.  For example, there are times when a complicated spreadsheet, with some minor VBA programming is needed to calculate something that is going to be needed only for that year’s close out.  Having the IT department create an application using the corporate standard process would add time, expense, and inefficiency to something that is needed for a very brief moment in the company’s life.  However, these tiny little apps sometimes pose tremendous risk to an organization if they are used to make business decisions and/or have operational risk, reputational risk, or audit risk (to name a few) and need controls to be in place to manage the risk.

What we found was that a minimal process that was very agile in its approach that required the bare minimum amount of documentation added very little impact, but now provides a comfort level to executive management, internal audit, and external audit as well as putting some structure around the risk management and mitigation.

This process is in the initial adoption phase and will be refactored based on the results and lessons learned before it takes on program level coverage.  In future updates, I will blog the good, the bad, and maybe even the ugly on how it continues to evolve in practice.  Based on initial results, I think that many organizations could benefit from the approach we used…

The whole process of assessing the current state was a very healthy activity for the organization. There were many people at both the practitioner level as well as management level that knew there was room for improvement and areas that needed immediate remediation. There were also people that initially were reluctant to believe that anything at all needed to be changed and everything was "just fine". In the final management discussions where all of the findings and supporting evidence was presented, no one could contest that changes had to be made.

The analysis and resulting recommendations were used to create a business case for change and an action plan which included creating a common process framework so that the organization would have a methodology that can support their varying development types with consistency and efficiency by leveraging common process practices and method content where possible. We will be using the Eclipse Process Framework Composer (EPF Composer) and as much OpenUP method content to supplement all of the existing policies and procedures.

What happens when the plug is pulled too soon on an initiative's budget?

Process implementation, process improvement, and process reengineering initiatives are no different than other types of project work when it comes to cutting budget. These types of initiatives typically span multiple years in larger organizations due to the sheer size of the target adoption population which can be from a thousand IT professionals to many thousands. So what happens when the budget for the initiative is reduced or cut too soon? Same as any other type of project work, the results and return on investment will come up lacking at best, will begin to steeply degrade at a medium, and at worst the organization is worse off than where the baseline starting point was, after tremendous time, effort, and money have been consumed.

The strategies we employ with our clients when adopting new and better process solutions or when we are helping to turn around an existing UP/Agile based solution adoption; we always have a vision of self sufficiency incorporated where we are training and mentoring the internal resources that will take over the roles and responsibilities that we engage in. This particular aspect sometimes gets eliminated by organizational management once initial adoption measurements show favorable results. External support can be reduced to quickly and the targeted internal resources have not gained sufficient experience in the role or training and mentor and sometimes not even in the role of a lead practitioner.

This often has significant negative ramifications to the initiative; it is amazing how progress that may have taken 12-18 months can be reduced so quickly. An analogy I like to draw is a group of people that encompasses the adoption team of external training/ mentors along with the internal mentors in training combined with all the other supporting roles plus all the project team practitioners that are valiantly trying their best to adopt this new process all pushing a heavy boulder up a hill. Just before reaching the crest where the momentum will begin to help continue rolling the boulder, some of the needed help to get it over the crest is removed.

What typically happens next is the forward progress of rolling the boulder is slowed, then comes to a brief stop, and ultimately begins to roll back towards the starting point. There are undoubtedly project practitioners along the way that gained enough experience and exposure to continue to use the new methods in their work, but as an organization, the ROI has generally peaked and begins a downward trend.
The new process begins to take on a negative connotation and the bandwidth of the remaining adoption team members is beyond an adequate level to provide minimum quality. On top of that, the fact that their level of expertise necessary for supporting the continuing project teams that are still on the adoption path is too low, and you can see where this is going, all the good work begins to unravel and finger-pointing starts to rule the day...