Don’t Do It All At Once San Francisco CA

provided by: 
Originally published at Internet.com

Some groups propose "big bang" projects where they try to change the world in one fell swoop. It comes along like a siren song: "Do this and all will be fixed." Groups looking at the IT Infrastructure Library often here this song and dangerously steer towards hidden rocks. Rather than risk all, teams need to take a step back and consider a phased implementation that aligns with the needs of the business.

The challenge management from a long-term, expensive project is the level of risk. This is both due to the amount of money required and the amount of time required before benefits are seen. As a result, some projects may not be approved.

A large process improvement project that is expected to take years to complete and cost millions of dollars will be viewed by many management teams as very risky because of the time, cost and potential risk of not attaining any real benefits. Even with a good business case, management must weigh investing much needed money and time on this project vs. other projects that may seem more likely to deliver the expected benefits in a shorter period of time.

A different approach is to break large projects into incremental phases that are discrete building blocks of investments, activities and deliverables. Take a large project and split it up so the first phase lays the initial foundation. Then the second phase builds on that and so on. In a sense, the large original project can be viewed as a program comprised of a number of smaller related projects that when combined will achieve the original objective(s).

By doing this, there is one vision ranging from inception to end state. It also reduces costs of each phase. Also, if the benefits do not prove out or corrections are needed then they can be made prior to the next project being finalized and funded.

Building on our earlier process improvement example, imagine that instead of trying to propose everything in one fell swoop the project sponsor keeps the large project definition as a roadmap to explain what needs to be done and why at a high level. Then, he or she identifies processes based on enabling and/or protecting organizational goals by selecting those most needed first, taking any dependencies into account of course.

The result can be a phased approach where each project has a focused scope, a relatively smaller budget and benefits can then be monitored at the end of each before moving ahead. This presents a much more palatable option for management as the expenditures are lower and if the concept doesn't prove itself then the effort can be aborted by not approving the next project.

Building Blocks

To convert a project into phases, consider the following example questions:

* What budgetary amounts management will be comfortable with funding? * How quickly management expects to see results? * What the level of risk tolerance from management is? * What resources are available at what times? * How does the business calendar mesh with the project timelines?

Armed with this information, look at the project and determine how it can be split into phases such the time frame, budget and benefits fall into the parameters set forth by management. In addition, you will need to take into account technical, process and human factors.

From a technical perspective, some projects will require certain services or technologies to be implemented in a particular order to make sense. A server, for example, needs rack space, power and network connectivity before it can be effectively used.

In terms of processes, they can have dependencies as well. Each process has inputs, outputs, and activities that take place. It may be that certain processes need to be in place generating outputs that then become key inputs to others. For example, in the world of ITIL, Configuration Management plays a key role in providing a logical view of the world to IT. Yet, to be timely and accurate, it needs Change Management in place to ensure that the Configuration Management Database (CMDB) is being updated appropriately.

From the human factors perspective, you need to take into consideration staffing, training, politics, resistance to change, compensation, etc. It should become readily apparent that the biggest success factor, or reason for failure, of most projects is the soft human factors side. Care must be taken to take the unique set of factors into account when architecting solutions and the projects that will implement them.

There are many ways to plan for phased projects. The key is to consider them in the first place because phased projects definitely allow can lower-risks for the organization when done correctly. IT organizations looking at projects that involve large outlays over a protracted period of time should assess if a phased approach would benefit their work and the organization overall.

George Spafford is a principal consultant with Pepperweed Consulting and a long-time IT professional. George's professional focus is on compliance, security, management and overall process improvement.