Six Steps To Manage (Project ) Mayhem

(or how to pull together project plans on the fly...sort of...)

IT seems to be filled with two things – basic maintenance (aka ‘keeping the lights on’) and new projects. Some of the new projects are IT related (new tools), but most are external facing. They are new projects the organization has determined it needs or wants.

When executive leadership approves a new initiative (we’ll call them all ‘projects’), they have determined that at a high level, the project will drive some specific outcome for the organization. Sometimes it’s to increase market share, sometimes it’s to improve business outcomes, sometimes it’s to reduce costs, and the list goes on.

As an IT leader, it can be very challenging to manage the almost constant onslaught of new requests and new projects or just new ideas to pursue. As an IT leader, how can you manage this process?

Use a Standard Framework or Approach

While there are many viable approaches, working with a standard format can help you quickly assess and plan for new projects. This approach, shown in the figure above, attempts to capture the process, which should be iterative, but not infinite. This means that it might take a few go-rounds to get things dialed in, but it should get closer and closer to complete at each turn. If it starts spinning and swirling (hallmarks of infinite), you’ve gone off track. These same steps are used for developing a project plan. The solid lines indicate information being formed, the dotted lines indicate information being presented and evaluated.

Start With The Vision – Where Should We End Up?

Any new initiative should start with a 1. strategic vision, even if those aren’t the words used to describe it. Of course, it’s great if you’re handed a fully formed vision statement, project charter or scope document. But since that rarely happens, you can listen for things like “we’re trying to achieve….” Or “when this is complete, we’ll be able to…” These statements are often made at the executive level in the organization. This step provides the information that goes into the project’s charter.

What Are The Things We Need to Achieve?

Once you’ve got an idea of the proposed vision, you can translate that into 2. operational outcomes. These outcomes are often formulated by the intermediate leadership level in an organization, such as the director level. The director has enough visibility into the executive level to understand the vision and enough operational expertise to determine the optimal outcomes. This relates to a project charter and scope statement. It’s here you also identify who’s responsible for this project both in IT and in the organization. The target timeline and budget should also be identified here. If the budget is open because the organization is waiting for you to assess the project, you should gain an understanding of the order of magnitude budget parameters. For example, is this a $100K project or a $1M project? Will this take 6 months or 18 months?

What Are the Required Elements to Achieve Those Outcomes?

From there, the management layer of the organization works with their subject matter experts to formulate 3. technical requirements. Will this require new servers, storage, network, or desktop resources? Will this require new interfaces? Will this require an information security review? Requirements help validate and refine scope statements.

What Are the High Level Steps We Must Take?

At this level, the technical aspects are defined and a rough draft 4. tactical plan is created. This shouldn’t be an enormous effort at this point because it needs to cycle back around for validation. To dive into detailed planning without executive validation puts the entire project at risk of missing the mark. This is the beginning of your project plan because you should have some high level (or even detailed) tasks starting to develop. This information is provided back up to the next level of management.

What’s the Plan Look Like Now?

The tactical plan gets translated into 5. an operational roadmap, which simply distills the tactical plan to fewer, higher level milestones or steps. The operational roadmap should include the high level milestones or tasks along with constraints, prerequisites, dependencies, and concerns. This should be clear, concise and short. You should have your high level tasks and milestones validated here. At this point, you should have the solid beginnings of a strategic initiative and the related project plan. This is developed by the mid-level of management and provided up to the next level of management.

Does Your Plan Align with Leadership’s Vision?

This should be validated by the executive who initiated this project. The goal is to ensure you have 6. strategic alignment with the organization and the original vision. This need not be a big, long, drawn-out discussion. Instead, it can be a fifteen minute meeting to share information and gain agreement or get clarification. This is where you gain executive approval, ensure you’re aligned (or that nothing has changed in the meantime). You should also validate timeline and funding sources as this point, before launching the project.

Iterative, Not Infinite, Revision

If you’ve missed the initial mark, you can swing through these steps again making the modifications needed to re-align. Think of it this way. If a boat is heading across the ocean and it’s 1% off course, by the time it gets to the other side of the world, it lands on a different continent. If the correction is made 100 miles into the journey, it requires a much smaller correction to get back on track. Using this same thinking, doing a few quick iterations can save you time, money and frustration later on when the project is in full swing and you suddenly come to the realization that you’re off course. But, once you’ve validated your course, lock it in and begin work. Infinite revisions will cause project failure.

Final Words

There is no magic cure-all for the overload some IT departments contend with, but IT leaders can make a big difference by working through a consistent, easy-to-use framework to validate work before starting on new organizational initiatives. Using an approach like this one, you can quickly assess and validate project work before starting and hopefully deliver better results faster and with less effort (or at least, less stress).