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:
- 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.
- 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.
- 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.
- 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.