The first six warning signs that a technical project might fail

Being a sysadmin means that you, from time to time, will be called into IT projects, and your role will most likely be that of Subject Matter Expert (SME). A sysadmin usually gets called in (too) late in the process, after the goals and milestones are already set. Most likely, these targets are, from a sysadmin point of view, too ambitious both when it comes to timelines as well as resource allocation.

The phrase, "We just need you to check on some documents and verify that they are OK," could be an introduction to your expected participation as a sysadmin in the project. Naturally, you have already figured out that your involvement will be much more extensive thanks to the already complete technical analysis that, in your view, looks like a barren wasteland. In this article, I explore the caveats behind the expressions "underestimate" and "overconfident" in technical projects.

So let's look at different components that build the picture. These pieces all revolve around the warning signs that an IT project already is or will soon be in trouble.

Note: This content is the first in a two-part article series.

It's shiny

Many IT projects are the result of skilled salespersons or proficient companies that have, across several meetings and communications, presented many colorful slides showing speed, progress, and above all, substantial potential savings. One or more product demos and perhaps even a visit to a reference customer have been undertaken, and those involved have agreed that this new software product is the best thing since Spam in a can.

Speed, progress, and big savings are the classic trigger-points for management buy-in. The subsequent business case is followed by a Proof-of-Concept (POC) from the provider. Given the right context, the product is probably brilliant, well needed, and a step in the right direction, so the concern is more about the context, the technical landscape, the organization, and the legacy application environment that dampens the ability for the new product to shine and deliver.

Wow-to-production

In a worst-case scenario, the POC is completed without the sysadmin's involvement. It is not until the product is live in production that the sysadmin is called in because the project has hit some technical snag or other barriers which the project owners can't resolve on their own. For example, in an international deployment, the POC installation-gone-production will by now behave like an obstinate donkey on a hippodrome. You are stuck with something that belongs in a small test lab but is now stretched until all control is lost. You are tasked with fixing it, and now tempers are running high, together with cost. This situation is the perfect playground for finger-pointing in a prestige-filled drama of name and shame.

It is surprisingly common for POCs to morph into production, which inevitably causes issues. With no real launch plan, production setup, capacity for scaling, or any thought on the user experience in other countries, everyone is in for a bumpy ride. Sysadmins have the experience and knowledge to advise and prepare for how a real production environment should look.

Our business is unique

"You can't compare us to other companies because we manufacture the things we sell." What I'm pointing to here is the urge to modify and customize products, so they EXACTLY fit the very specific way of working or thinking that the product is intended to match. This view is, of course, not a very future-oriented way of implementing something, but it does protect most colleagues from having to change either mindset or way of working. So without even trying the product as-is, extensive changes are made, and existing ways of working and thinking are handcrafted into the software product.

It's better to use it as-is for the first few months and only then apply a handful of adaptations that will not in any way affect the manufacturer's release schedule for the software product. Examples of drastic changes could be: changing some sort of back-end database, modifying user interfaces and views, rewriting standard queries, and changing tables. As a sysadmin, you know all too well the risks of turning to the dark side and starting to use free text fields to store keywords, dates, names, or time stamps.

Changes can, at this early stage, be implemented without using the standard change management process, which also means necessary documentation is missing, thus leaving a huge gap to fill once the project is handed over to production.

Surely all of the changes are done in good faith and the project team has no doubt a burning desire to create something truly awesome. But surprisingly, there is often no consideration as to what happens when the base product is upgraded.

Developers and sysadmins can together make a significant impact on managing changes that determine how easy (or hard) the software product is to update.

License cost

Many POCs are successful and the results are often very promising. As an example, going to the cloud usually looks very convincing in the early stages. Another opportunity might be some clever analysis tool that collects data and turn it into valuable information.

So the initial expansion of a new solution software is often positive, and there is no concern, but once the real production volumes start to enter the stage, the cost takes off. Many software releases have per-user licenses, while other services have a cost-per-Megabyte or a mix of both.  Then there are things like developer licenses, support licenses, and server licenses - which can be tricky in virtual or on the cloud. Licensing cost is a topic where sysadmins and finance need to collaborate to avoid unpleasant surprises.

Backups (not) included

When setting up a POC in a test environment, there are seldom any discussions about backup. Once the solution enters production, those sorts of things are already handled, and "everything is being backed up anyway." This mindset is what I would refer to as "overconfident," where the lack of understanding of how backups actually work, how long backup jobs take, and what the actual backup costs are is overlooked. With new technology, there is often the need for new types of backup that might require significant investments in service or hardware.

Security and Anti-whoops

Unwillingly placed in the back of the bus are teams that have perhaps the most significant role in the company when it comes to protecting assets such as information and business operations. I am referring to teams that are responsible for security and antivirus. If the IT project is initiated or driven by a business unit, chances are good that nobody thought to include them. But once these teams are included or become aware of the new project, they have loads of questions and concerns that can easily be perceived as blocking progress. Naturally, the situation would have been vastly different had these teams been involved from the start. Through daily operations, sysadmins are in contact with both security and antivirus teams and again play a pivotal role in the overall technical landscape.

Wrapping up

These are the first six signs of a failing project. Just addressing the above topics will take you a long way toward resolving problems with IT projects. In a followup article, I will discuss the remaining six issues, as well as provide a checklist that you can use to help make your life easier.

[ Want to test your sysadmin skills? Take a skills assessment today. ]