This is my third and final post in a blog series regarding application portfolio modernization projects. Specifically, I have covered different approaches and processes for making smart application portfolio decisions.
As a short recap, in my first post I discussed the business costs of doing nothing, even in the midst of a largely flat or even lower budget cycle. I also addressed the risk associated with an aging and monolithic application portfolio stack.
In my second blog post, I talked about experiences shared by CIOs regarding the options taken, ranging from whole scale application overhaul projects to iterative approaches focused more on process improvement or quality improvement in the application.
In this last post, I will focus on the first option of migration approach, which is to undertake a full transformational project that takes the existing application workload off of a mainframe platform and moves it to a distributed platform on Linux, Unix, or Windows.
What are the options for approaching such a project?
It all depends on the application characteristics within the portfolio. To understand this requires a thorough assessment of technical complexity and associated risk, a process which helps determine the best approach to use in the migration.
The assessment is used to evaluate the application itself, including main COBOL code, other legacy language code components, the transaction processing environment (such as CICS), and batch processing. It is also important to review the application touch-points, such as how an application interfaces with other applications in regards to monitoring tools, batch interfaces, and reporting tools. Once the entire application and interface is fully understood, a migration approach and strategy can be developed. The assessment findings process also helps to determine the best way to stage the migration and line up the teams in the build, test, and deploy project stages.
In most cases, a strategy will involve an incremental approach to migrations and a careful design of the project based on business and technical requirements. One typical portfolio approach is to start with a re-host of an application that has the least risk and complexity. This approach allows the IT team to get comfortable with the entire migration process, build expertise, and boost confidence in the target platform's performance capability versus running on the mainframe. Sometimes referred to as a pilot, it gives the organization a quick win to gain buy-in within the company.
Program management is the key lynchpin in any project, regardless of approach. Any migration will involve multiple teams across both the internal and vendor groups. It takes an experienced program manager with a strong background in computing platforms and complex technology projects to be able to orchestrate and execute the program.
Just as the quality of program management can make or break a project, organizational change management (OCM) presents a similar challenge and must be handled effectively. A common failure in most IT projects, ineffective OCM is also a culprit in our history of migration projects. Often, the most overlooked aspect of a project is the "human factor" of how a job actually changes from current platform to target after the migration is achieved.
One of my favorite approaches here is to have a skilled migration consultant expert lead a series of casual learning lunches in which he or she shares knowledge and experience at the work site. War stories and victories over a pizza go a long way in accepting change.
It all comes down to the basics of IT project management that has dogged our industry since the '90s. Migration projects aren't exempt from this basic tenant. While transformational projects are serious undertakings that deserve careful design and planning, the payoff is the hard dollar savings in operational costs that boost ROI better than any other technology project out there today.
Okay, I admit that I stole the idea for this title from Jim Collins. Collins introduced the
world to BHAGs (big hairy audacious goals) in his book Built to Last. It's a simple yet truly powerful concept.
For those who have pursued BHAGs, you've probably stepped in a few BHOCs (big hairy 'Oh craps!') along the way. Sometimes you slip and fall immediately, but often you don't know you've stepped in a BHOC until something begins to smell funny.
Good leaders know how to effectively guide their teams through problems, big or small, ensuring they don't fail in achieving their mission.
But maybe you want to be better than a good leader. Maybe even move up to great? Then learn to spot BHOCs before you step in them. Here are some basics:
1. Gather your team (especially those in the trenches) and other stakeholders and brainstorm risks around time, dollars, scope, quality, people, technology, etc.; ask them what they see as the biggest "Oh craps!" facing the effort
2. Don't judge any idea or you'll suppress risks (they'll still be there, you just won't know about them!)
3. Have a mechanism to continually listen for and capture risks throughout the life of the effort
4. Assess all risks based on probability of happening, and impact if a risk should occur (You will have risks from low probability and low impact, to high probability and high impact)
5. Document how you'll handle each risk:
a. Accept as is
b. Abolish
c. Avoid by modifying the project
d. Actively manage/mitigate
e. Assemble a contingency plan to execute if a risk occurs
I've always believed that the biggest risk facing any project is not identifying the risks that can sink a project. This is one BHOC that can easily be abolished.
All projects experience BHOCs. But with some early, honest and open risk management, you'll have a lot less crap to deal with!
Read more strategies and trends for IT leaders at www.CIOUpdate.com.
John D. Hughes is founder of GrowthWave, an Interim CIO/CEO Advisory firm in Seattle, WA, and author of the recently released leadership fable, Haunting the CEO: A tale of true leadership in an era of IT failure. John can be reached at jhughes@growthwave.com.
|
