No Time to Plan

I am going to begin to count two things I hear on a regular basis. First, I want to map the number of times I hear from IT leaders, beginning a new project, who say something akin to the following: "I have so much to do, this project is so HUGE, I really don't have time to spend doing any more planning. We have to get something actually DONE." Next, I want to capture the number of times I hear from their counterparts, typically 6-12 months into just such a project, who are saying something not unlike, "Why didn't anyone TELL me that? If we had know that at the start of the project we would have been so much better off. Now we have lost weeks (sometimes months) of time."

I can tell you I hear both statements on a regular basis. And both are accompanied by a large amount of energy, and all too often, negative emotion. The leader who is at the start of a project of significant size is often challenged by stakeholders and team members who have spent a lot of time going through a complex decision process to find the "right solution/vendor/product". In my area of work, this can represent many months, and sometimes even years, of effort. Often, stakeholders who are not familiar with the nitty gritty of technology (read end-users and executive sponsors here), expect that once the decision has been made, the vendor identified, and the various software systems selected...there is nothing else to do but open up those boxes, put the software on machines and take off. You're done!

WOW! Holy not quite, Batman.

Unfortunately, I also frequently run into IT and project leaders who can easily fall into this kind of thinking, or something similar. "We can take it from here, we don't want to bother the executive/end-user/non-techies at this point. After all, they were getting pretty testy by the end of the selection process. Besides, we did a great job, we made the right choice, nothing left to talk about at this point...let's just get the stuff implemented." This is when I hear the first comment. Our planning is done, now we just need to get going. And they jump right in. Most often, everything runs just fine...to start. And on occasion, particularly when there is only a simple system being implemented, this approach might work. But not most of the time.

Going "fine" is not how it goes with complexity. And that is where architects get involved. Often, the first bumps in the road occur as soon as the project involves trying to integrate multiple systems, passing data from application to application, cross silo's of work or functionality, or create a common process to replace previous (differing) approaches that exist in more than one division or stakeholder group...and that is when everything starts running amok. At first, the challenges may not even be readily apparent. But at some point, it almost invariably turns out that a decision made for the best of reasons, and with the best of intentions, early in the project by one team impacts another team farther down the line. Or a change in direction by a particular area of business results in major project impacts that require significant rework. This is when I hear the second line, and it is not typically a "good news phone call".

In the best case scenario, we can make adjustments that help get the project on track relatively quickly, but I have NEVER seen this take less time than it would have taken to have done the work of planning at the start. Invariably, the team that "saved time" by eliminating the initial "extra planning" early in the project spends at least 3 times more time, effort and energy getting back on the right track, doing rework, and revising errors than they would have spent getting a Roadmap and foundation in place. And this is typically under stress with unhappy project team members, frustrated end-users, and very irritated executive sponsors.

So how can you avoid this entire issue? I recommend the following:

1. For complex projects, start with an Enterprise Architecture (EA) approach. Start right away and make it formal. This means documentation. If your IT department has not completely exploded, you already have pieces of your EA in place. Gather that information together and review what you have. If you are like too many IT teams, your documentation is somewhere between non-existent (inside someone's head is not documentation by the way) or dated. Take advantage of the project at hand to update as you go along.
   
2. Document your Enterprise Application Portfolio. This is absolutely critical. And as basic as it is, many organizations skip over this step. If your environment has even a moderate level of complexity...don't make this mistake. Without this information in focus, you are flying blind. In contrast, once you have your portfolio clearly and simply documented, you will find it much easier to plan when, where, what needs to be done, and make a coherent case to others with evidence in hand.
   
3. Partner with your vendors. I am serious here. If you went through all the effort of choosing a specific vendor, and you did a good job, use their expertise early on to plan the implementation. If you don't trust them enough to work with you as a collaborative partner, you may have selected the wrong vendor. Any good vendor should be ready and willing to work with you to outline a plan that takes into account not only your team's goals and expertise, but the vendor's knowledge and experience gathered from multiple implementations, knowledge of common integrations, implications of various decisions early in the project on long-term agility, etc. This will cost you some additional dollars in services early on...and invariably it will save you money and time, and provide you with more options as your project moves forward.
4. Develop a Roadmap and USE IT. The Roadmap concept was outlined in a previous entry. This is a basic tool for any good EA approach, and essential to your efforts. Make it clear where you are starting, where you are going, and metrics you will use to measure success. Define tactical steps to go from current state to future state. And don't do this just at the start of the project. Update your Roadmap as you move forward. And use it. Bring it to discussions with end-users and sponsors. This means it has to be simple enough to explain to non-techies quickly. Being able to keep this high level view available for everyone from end-users to IT will help to establish priorities, explain direction to multiple teams, and keep focus across complex and many faceted efforts.

In the end, if your IT environment is complex, you will either spend time planning, or spend time fixing the problems that come up from not having a solid plan.The first option may not be very exciting, but the second alternative can be overwhelmingly stressful, and costly.

In the end, you want to succeed, and to do this, you have to just accept the reality...if you are going to run complex projects, your major responsibility as an IT leader is going to end up being planning and managing plans and projects. And, once you have a plan in place and your tactical efforts and activities mapped to that plan, you will spend most of your time supporting your team and making sure you are keeping the strategic goals of your organization clearly in focus and adjusting your plan and tactics when needed. This typically means that just about the time you have a solid plan in place and your team focused on tactical activities...you are going to be going right back to review your plan and update it while your team is executing tactical activities. Planning is not a one shot deal, it is an iterative process, to do it well, you do it early, and review it often. It's all about architecting work.

Architecting vs. Building: Introduction to Roadmapping

In the course of my "real job" I work with colleges and universities to get the most out of their significant technology investments.

This is a challenge in any market enterprise, but it presents a greater challenge to those in higher education than many others because of one factor, complexity. The average college or university runs a wide array of technologies that support everything from student information and academic functions to financial records, human resources, financial aid, facilities, security, and more. The reality is that even a relatively small college can easily have more technology complexity than some relatively large corporations.

Unfortunately, the information technology (IT) team that supports most smaller colleges or universities tends to be much thinner than that supporting a corporation. This creates several challenges. First, there is a tendency to be completely focused on tactical efforts. A thin team in a complex environment is frequently taxed to merely keep everything running smoothly. At the same time, there is often little time available to plan beyond the immediate demands at hand. When you add the consideration that education and research (the core "business" of higher education) are dynamic processes, and that the typical higher education environment is full of smart people (stakeholders) with great ideas for new, nifty technology uses, the list of demands for IT tends to expand constantly, often at a rate that exceeds the team's ability to execute...resulting in an ever expanding list of tactical activities, and stakeholders who are demanding that their needs be met.

The result of this set of realities is that it is not uncommon for IT departments to spend everyday, all day, building...with no time for architecting. And this can work...at least for a while. In fact, as long as there are unconstrainted resources (capital and human) this approach is sustainable. Unfortunately, the minute there are limits on resources (and for most higher education systems this is occurs quickly) problems arise. All too frequently, individual projects become silo'd efforts, and energy expended to support one activity are not considered from a broader perspective. Priorities tend to be established based on either the crisis d'jour or "whoever is screaming the loudest". This creates an environment that is less than optimal for those people who work in IT, who end up working, more often than not, under stress.

What can be done to alter this kind of challenge? How can an enterprise move from the tyranny of the urgent to an architecting approach? The first step is to develop a Roadmap.

A Roadmap should outline the major objectives for IT in alignment with the key goals and objectives of the enterprise. To be successful, your Roadmap will need to include: current state (where are you today); clear targets for future state (where you want to go); metrics and benchmarks that map to both current and future state (how you will know when you have reached your goal); and a phased approach to move from current to future state (the "road" you are going to take). Once the phased approach is mapped, the IT team can map tactical efforts and projects across more than one area, and efforts will increasingly support an architected aspproach, as opposed to merely building to meet immediate demands. Without a Roadmap, efforts tend to be driven by demands that are less than logical. With a Roadmap in place, IT can begin to take a more planned approach to responding to multiple demands.