Ambitious Stupidity: Why Hope is Not a Strategy for Managing IT Projects

This article was originally published at SmartFile.com

Recently I was at a conference for business and one of the speakers, when talking about scaling up a business to become larger, said, “Ambitious stupidity is the most dangerous type of stupidity.”

That has stuck with me ever since because in that moment I realized that this is something we deal with on a regular basis when managing IT projects. All too often, we see IT projects that new and prospective clients have undertaken without truly planning for it as well as making other major assumptions that should have never been made.

Ambitious Stupidity Makes Projects Fail

Consider a company who wants a world-class infrastructure but doesn’t want to pay for world-class equipment or expertise to deliver this properly. They end up pouring money into a project that is either destined to fail or, if completed, will not perform or work anywhere near the original expectations. This, dear reader, is ambitious stupidity and it’s a plague upon the IT earth.

Business leaders, however, are not always to blame these failures. Often, the IT project managers, staff or support is ill-equipped to fulfill the vision of the leaders and either doesn’t have the resources or talent to accomplish the task. However, in their defense, many IT personnel on staff tend to speak to what they perceive are the wishes of their superiors without fully understanding the vision. They will then make assumptions as to the goals and actual budget, which they usually think is shoestring, the leaders are willing to spend to achieve as decisions like this are important in driving and overall business forward.

What happens in these situations is that everyone ends up rather disappointed in the outcome. The leaders do not see their vision realized or, worse, believe what they want is not obtainable by available technology when it usually is. The IT implementation staff is either not proud of the work or winds up defending a less-than-optimal job. Ultimately, they end up hoping that whatever they did implement will simply work well enough to weather the storm of the leaders.

Hope is not a strategy and what it speaks to is a lack of understanding, planning, preparation and implementation. So, let’s walk through how an ambitious project should be addressed and run. While I am in the Cybersecurity and infrastructure world, truthfully these steps could apply to any kind of project. This is a high-level view of overall project strategy with the emphasis on removing misunderstanding and hope from the equation. We want to build project plans that are concise but detailed enough so that no options and avenues are left open to chance or misinterpretation.

Seeking to Understand

This first step could arguably be the most important step of the whole process. Projects often fail because everyone involved with said project doesn’t truly understand the other’s wishes, goals or designs. If you are the Project Manager trying to make a CEO’s vision of a project come to fruition, then nothing can be left to chance.

Understanding the overall vision and strategy is incredibly important but so is the minutia. Do not overlook this last point. You may be able to build a database that does everything asked for in terms of data or reporting but if the design is clunky or non-intuitive the project could be failure purely on minor points alone.

The perfect example of this is any company previewing potential new software packages. If they are looking at three different solutions, odds are all three will do exactly what they need in terms of data input, report queries and analytics. So why does one software package typically win out over another, price not withstanding? It’s the interface! Now, here’s the kicker…in terms of logic, the winning interface may not necessarily be the most logical or intuitive.

For the same reason employers tend to hire employees that match their personalities those same leaders will select software that fits their workstyle and flow the best, even if it costs more. Thus, if you’re designing a project from the ground up, understanding this workflow pattern and potential design layout is rather critical.

Get Everyone’s Buy-in to the Vision

What turns a lone nut into a leader or a visionary? It’s the first follower he or she obtains. Observe:

First Follower: Leadership Lessons from Dancing Guy

If you are this leader and you have an off-the-wall idea or vision for something that will drive your organization forward, this step is critical for you. It’s not enough for your employees to agree to do this, after all, they’re paid to do what you tell them to. You must win them over to your side and you must make it about “us” and not “you.” This will motivate the staff and offer a level of dedication to the project to ensure it’s handled with the care it may need.

If you’re the first follower to buy into this project or vision, then it’s your job to affirm the vision and show the others around you, usually employees under your management, that this is indeed the best path forward. As the video above shows, everything hinges on you and this is not a role that can be easily faked. You become a general in this newly formed army and it’s your job to help everyone realize their important and vital role.

If you’re a follower that has bought in, then step one of this article is for you. Gaining the intimate understanding of the minutia, or at the least minutia for the part of the project you’re working on, is of paramount importance. You will actually bring this project to fruition. The leaders may talk big picture but you have to make it happen.

It’s important to note, though, if you’re the leader or first follower and you abandon this project or let it slide, you can do deep damage to the morale of your organization. You can be seen as ineffective or not willing to follow through on commitments. Thus, if you come up with another visionary project it will be significantly harder to get the same level of buy-in from the troops.

Plan the Stages with Realistic Timelines and Goals

Now that everyone is on board and drinking the Kool-Aid (oh yeah!) it’s time to understand the scope of what this project will entail. Leaders have a tendency to want everything immediately or at least push timetables to bring their vision to fruition as fast as possible. It’s the job of the Project Manager and developers to explain why the leader’s timetable is not realistic and this is where it can all break down.

In one sentence this point is simply this…It’s all about the delivery.

Really! There is nothing more effective to getting the buy-in for realistic timelines and goals than subtracting from the overall vision of the project to ensure faster delivery. Allow me to explain:

Let’s assume, for a moment, that this project has twelve goals that need to be accomplished in one year, meaning one goal per month. Let’s further assume that the leader of this project wants to accomplish this overall project in six months. A shrewd Project Manager will not try and whip his people into performing one goal every two weeks to make the deadline unless there is literally no other choice. Rather, he or she will approach the project with a sense of “what goals can we cut to make the overall project work with in this timeline.”

The leader is now faced with a choice of having to either subtract from their overall vision and end up with less than desired or understand that to fully see their vision created it will take more time, the truly best leaders will wait and let the project be done right.

There are exceptions, of course, to this tactic. If the company has an emergency that requires immediate action, then the timetable may be forced to be shortened drastically with the understanding that the goals not accomplished initially to bring the project live will need to be revisited after launch. Also, if a leader is inflexible, then the project will be done without the full buy-in of the now stressed employees and it’s almost guaranteed that mistakes will be made along the way that may harm how the project goes live.

Understand the Budget When Managing an IT Project

Now that we have realistic timelines and goals in place, we start to form a realistic picture. Of course, most people have an idea of what they believe their project will cost and they’re usually wrong. Sometimes they’re not even in the ballpark — the ballpark is probably an Uber ride away from where they usually think it should be.

Of course, everything is relative. A $2 million project that ends up being $3 million is not the same as the $100 million project ending up at $101 million. The point is to understand that your idea of the cost may not be realistic.

In this sense, this point of the article is interchangeable with other — get a more accurate picture of the budget before you round up the team. Leaders need this information, in a big picture sense, early on and the project manager’s goal is to deliver a realistic cost for the whole project.

This realistic cost should always include overage for the project and this overage should be realistic.

Usually, 10% to 20% over projected cost is acceptable unless the project will include unforeseen issues, such as how to develop a solution for a problem that exists but currently doesn’t have a solution. Most projects, though, don’t have that issue so if more overage cost is needed than the standard 20%, then it may be time re-evaluate who exactly is going to be doing this project and if the right people are in the right place.

Once the budget is finalized and presented to the leader the “delivering results through subtraction” method is once again effective. As an example, we do not lower our project rates or cost. If we are doing a $100,000 project and a potential customer wants the project done for $80,000 we will not accept the project even if it’s still profitable for us. Rather, we will begin removing options to get the project down to that price. Therefore, the customer understands they’re getting 80% of what they originally envisioned. Prices are prices for a reason and while we want to work with everyone, not everyone can afford the full solution.

This process of scaling back will either allow the Project Manager to get the budget needed to complete the full project or the project will be scaled back to match the budget required. Either way, everyone is on the same page, as they all should be right from the beginning.

Implement with Communication in Mind

This can make or break the execution phase of a project. Imagine you’re 1.5 years into a three-year project: 50% through all of the goals but still a long way to go. In the same way that a person can drive fifty miles in a car from one place to another and not remember a single thing about the trip, projects are on autopilot for much of the way. Without proactive communication, the details can be lost or delays can occur.

Setting up a regular schedule for communication between the staff and the project manager and also the project manager and leaders is critical. However, just setting up the schedule and delivering on it sometimes may not be enough to keep the project on track especially if it is long. This is where proactive communication comes in.

Basically this a technique to keep the project on track and in the mind of everyone on the team. This responsibility falls to the Project Manager. He or she should be seeking “micro updates” from their people and then delivering those results to the leader as a “micro update” as well. These micro updates are not planned events, as planned events tend to get repetitive. These updates are done in passing and take seconds. Everyone walking out to lunch? Time to ask how it’s going or where they’re at. Most people will respond in the vein of “Good. I’m on X right now.” That’s it.

A project manager will know where X fits into the overall plan and therefore gets a quick understanding if the project is on track or not without having to dive into detail. Leaders also love these updates, as it takes no time and they also know it’s not only on everyone’s mind but also in progress. The project should deliver this news also in passing, “Oh by the way, Steve is working on X. We’re right on track.”

So…What Now?

Clearly there is more to managing IT projects than the above points however without these critical factors, virtually every project is going to fail is some way, shape or form. There is minutia in every step that needs to be addressed and planned for to ensure each step or phase of each goal or milestone is achieved. Just don’t forget reward all of the people that made this project and vision a reality!