Project zombification, the business of the walking dead

office zombies that draw the energy and passion of your team

Here are a number of situations in which the essence of projects is killed. The result transforms projects into real office zombies that consume the energy and passion of, otherwise, talented and creative designers, developers, managers and entrepreneurs.

Zombification of a project occurs when a finite thing, that should have a start and an end, gets transformed into a long, operations-like, daily routine. It will spawn on its own from the proverbial “about one month”, to a year or more with zero results. As a slightly true rule,

when the deadline becomes foggy get ready to fight the zombie in the fog.

The reason for zombification is the infiltration of virus-like bad practices into the approach of the team. These bad practices mutate the, once fun and lively, project into a slow sloth, that nobody enjoys, and which acts like a mythical business sucubus.

Here are some bad practices for whom i required months of isolation therapy afterwards because of zombie interaction.

UX is tricked into UI

Probably the root of all evil. The good ol’ UX waits to be designed and nobody even notices it. Catchy visuals, smooth animations, hours of work poured into pixel perfect client side implementations, but no explanation exists for why does the app have a dashboard, what is the user’s ideal flow, what is the sales funnel, what is the main activity funnel — nothing.

Developers have no idea how to implement their OOP, because no UX means that out of some Photoshop comps they can hardly identify more than isolated database tables. Nobody took the time to make a user story, to define what is the main information the app handles, what is this information’s properties and why are each one of them significant: here come ORM code generators for making so called “models”.

So the user experience is watered down and instead an user interface is produced that servers basically as a glorified mockup of some nice ideas, emanated by whomever initiated the project. This bad practice is so extended that articles upon articles are revealed on a simple google search about how UI is not UX and how the very root of the problem might start with the universal hiring of: UX/UI designer.

For this particular bad practice let me draw a parallel with the advertising industry in which i have several years of direct experience. For the high risk, expensive and closely scrutinized activity of producing a TV, print or radio commercial, the art directors — which would be the equivalent of your UI designer — almost never produce the whole thing on their own. You’d get at least a duo of copywriting and art direction, if not even involve a bunch of other people from the brand manager to the client service executive. Because, you see, apart from the visuals and headlines and catchy USPs, the thing needs to have a story, a flow, a meaning that would highlight the benefit for the consumer. It must show clearly why the consumer should throw their money at you. That’s UX in advertising. You can’t do it with UI only, no matter what you sell.

Flat, 10% rounded corners, single page parallax html5 angular

This is known in the scientific community of web development theorists as the “buzzword syndrome”. Because of some mistaken stakeholders, the project must be built according to the summary of the latest “A list apart” feed combined with the TechCrunch trending subjects and some HN pizzaz.

It doesn’t matter if developers can’t figure out how to cache the assets — they are flat so we’re good. Never mind nobody ran a usability test or that the product manager forgets how to use the product on a daily basis — as long as all the corners are rounded (to match everyone’s Apple display bezels) we’re set free of any problems.

But, while coders and programmers suffer very often from this bad practice of infesting specification with buzzwords — for example “build it with angular and have a node backend for this stateless landing page” — the most hurt are visual designers. Trend conformance, as observed by others too, produces so many bland results and zero creativity that eventually they drop using Photoshop and revert to MS Paint instead to ease the cerebral burden.

Its really one of the most intriguing bad practices since there are countless examples of huge products built on proven grounds. However its easier to build a PR scheme if the app “RoRs”, isn’t it?

IA is fooled into MVC

Probably a mutation of the project zombification virus released into the wild by 37 Signals. Its adoption was so wide that it became practically immune to any forms of cure. You can throw all your UML plans at it, its not gonna have any effect.

This bad practice acts by replacing any kind of prior planning about how the application will be built, with the proven knowledge that it’ll use MVC. The most common implication is that all the tables are models and we’re done with IA. Who needs an information architect to create a coherent data model with proper inheritance, logic foreign keys and clear access to the future object’s hydration? Nobody, and even more, we’ll hire a database consultant only after we’ve built hundreds of tables with code generation tools provided by our generic and well intended framework. Poor database admins, they will be hunted down by the zombie project armored with a never ending stream of impossibly poor queries.

Also, another side effect of this bad practice is the worldwide spread ignorance of the very features platforms offer because, hey, if its MVC, who needs a database view, a stored procedure or a server side data collection daemon … seriously!

Warning! These are the zombie projects that upon a successful attack spawn ignorant professionals which carry on the contamination to other projects too.

Brick-a-brack projects

It’s also called the poor man’s MVP. It has to be done in a week. Nobody dares or cares to count rationally, or just add up, the estimate time that should be poured in. Then, surprisingly, because of good talent, in a week, the project becomes a fair idea to show to close friends, but instead its showcased to VCs as the next yacht producing IPO and from there on the promising little foundation gains monster additions.

People who had projects zombified by this bad practice are surely worn off already by random and semi-random admin panels and wizards, needed impossible screen scraping, countless strikingly similar features implemented as separate application modules, or, the worst, 180 degree turnarounds from last week’s idea by an improvement suggested in some video call, a small “improvement” that is requiring whole codebase refactoring.

These are the zombie projects that tend to have the most mana of them all. They appear to never have a solution, an end, a vague idea of when the absolution will descend upon the poor project team members, that are throwing their lives away fighting with it. Even if you somehow escape these zombie projects’ deadly stalk, they’ll come back later on to haunt you and wake you up at 2 AM with servers gone MIA and customers loosing their hard worked content, just because of some wrong flag being set in some table that nobody thought was still in use.

PM is bamboozled into daily stand-ups

This bad practice is a mutation of an otherwise friendly foe called “Agile management and its manifesto”. What was thought initially to be the cure for project zombification, later distilled into SCRUM practices for even more efficiency, a project vaccine really, was apparently defeated by superior zombie cure resistance.

The immediate effect is having no idea what phase the project is in, even after months of sprints. People get into automaton mode and relay their previous day’s wrote lines or icons produced then quietly wait for the others to do the ritual, all just to advance the day before lunch break.

The late observed effect is the crippling to death of the project’s critical path, its spine some say. Daily standup in (and weekly sprint out) there is an endless stream of stories which get backlogged because nobody took the time to think about their dependencies, their natural order or the implications and correlations with other stories. Epic stories are non existent: you have to estimate, no questions asked, and you shouldn’t care since you’ll re-estimate next week anyway.

In fact, this zombie project is the brainless type, with no actual project manager in charge.

Everything is fine until its not

Also called the enthusiasm backed bad practice. Happens a lot on fresh seeded ideas, angel backed revolutionary products or even lower profile marketing websites or intranet applications. The general symptom is that there are no problems whatsoever as so many weeks go by. Then, suddenly, people are fired, management changed, direction switched, code trashed, zombie project apocalypse starts.

Most hurt by this are, as always, the employees — the lower on the chain or outer on the circle, the worse they get hit. Plenty of folks are churning away happily at their three hour a day tasks that they’re assigned, until the project has a relapse into zombie mode and they are slapped with a slew of bad evaluations and logic defeating managerial reviews. Sprint after sprint is being completed, and with the required party thrown too, just to suddenly be attacked by the project that got switched into a fixed-deadline-waterfall soaking the team. Nobody seems to count the increased velocity, the outstanding quality code produced, the superb UX resulted in applying clear fear free principles in managing a cross functional team, just because suddenly, out of the blue, Steve Jobs appears in ghost form in the meeting room screaming “Rrreaaal aaartiiistsss shiiiipp!!!”. Be advised, these words are a magic spell to turn a well intended agile project into a powerful level ten zombie, that takes a dozen morales a day into oblivion with each strike.

This last one is such a wide spread bad practice that you cannot even hope to escape. It manifests in various unexpected forms: “it doesn’t matter that its great, if it won’t make any money”, “how do our core 10 users, which we know by name, benefit this”, “we must perfectly match our estimated sales plan” — all having one simple description: large truisms that fail to be useful in the context in which they get used.

The projects affected by this mutation converts to a guilt generating, and stress feeding, personal life deprivation for all involved. These are the zombie projects that leak outside the office into the home and drive significant others mad or distant (indeed! a weird and scientifically unexplained result).


Truly, I am sure you’ve seen plenty more other mutations of the project zombification virus in the wild. I hope, and dare to dream, to the day when the advanced minds of think tanks and labs found in the academic world will take this huge waste of human potential seriously — and, maybe, with a bit of investment and trial and error, a true cure for the virus will show up in the form of some kind of mutual agreement upon best practices, task durations, the universal biases people have and the acceptance of these biases and so on; i hope to get to see this wild mix of ingredients making a business vaccine — and then getting amused by the crowd of truthers that will refuse it because it gives way too fast stock options monetization to the initial hires.


Thank you for getting informed and take good measures to stay business healthy. If you care for others (shameless guilt exploitation) click the recommend button below (there was the call to action). Cheerios, Andy.

Don’t run out of money

Iced budgets are better than ice cream

Walking on water and working by specification are possible if both are frozen.

Edward V. Berard

True but add frozen budgeting to the mix.

In spending money, like in all the other areas of a project, you will find unexpected situations, situations that don’t conform to the original plan. When you find that in your path i have one truism for you: don’t run out of money.

The goal of a frozen budget is to always have enough money for what is left to do on the project. Don’t step aside, don’t upgrade expectations in the middle of the gantt’s critical path. If you find that some acquisition is really, really required then buy the cheapest you can get that does the job. Remember: that does the job.

“Made in China/India” is always an option to keep your budget frozen.

Frozen budgets are very important in case the project fails. It will indeed feel like a lottery ticket — you risked, you lost. But if you alter your initial budget and spend even more and then the project fails, it will be like a bad casino experience — you will constantly wonder what the hell got into you that made you go on and spend all that money on nothing.

Project wise, i’d rather have a working bicycle with Chinese wheels than a non working one with original german wheels. The initial point of even starting a project is to, well, wrap it up. You will always be able to iterate and make it better later.

As you manage the budget of a project i learned that when you need to purchase cheap its all about spending on functioning, not on reliable. The only thing you have to worry about is for the cheap product to work. It most likely wont last, but if it works enough time its actually buying yourself the opportunity to iterate on the project later. Cheap doesn’t mean not working. It means less reliable, less supported, less sophisticated but it does the job, even if sometimes with less performance.

But don’t fear cheap ONLY as long as its in the middle of the action. Have the guts to assume responsibility and go for that indian team ☺ However, if cheap arrises as an option at the planning stage don’t choose it. At the planning stage you should choose optimal. And then, later on, at the iterative stage you should choose best in class.

Keep in mind that frozen budgets are not about self esteem or efficiency but about not running out of money. If the money finishes before the critical path you are doomed. It will turn the project into ongoing operations in a snap without you even noticing because usually the missing part of the budget will eventually be put in place by crumbs and leftovers from other projects, other departments, other managers and so on.

Don’t drop features, make them less.

Less features is really a motto for agile projects in the planning stage. But what if the risk of underestimated effort for features happens? Lessen it. If its critical don’t drop non critical ones but reduce the underestimated one in size and quality. If its not critical drop it all the way. Non critical tasks/features that spawn as underestimates are the most dangerous events in a project, since usually these cannibalize half of the project. Drop them like they’re hot, as soon as you notice the baseline to be lagging behind.

These dropped non critical, underestimated tasks will get a chance to be revised later on in the planning of the iterative stage so don’t feel sorry ☺ not you, nor your fellow dev team. Have patience and stay focused.

Deadline Dread

There are three types of deadlines: rational deadlines, abstract deadlines and real deadlines.

Too often lately “agile” has become either an excuse or a “solution” for deadline phobia. Because things cannot be endlessly fiddled with, generally any stakeholder involved in the development process will, at some point, require something done in a certain timeframe.

One of the problems of deadlines is that they are wrongfully understood as the end. Here comes Iterative Development to the rescue: deadlines are just different stages that the product goes trough.

Another problem with deadlines is that they tend to be perceived erroneously as huge walls that are approached at full speed — and just because of that they cause stress and poor execution.

When a deadline is regarded as a roadblock that you’ll smash into, unless you can somehow do a stunt on it, the solutions to come up with are poor: bloated teams, cut features, sliced specs, dirty hacks, bug ridden results.

A deadline is just this: the end of the timeframe that starts now.

When you look at it this way it no longer frightens you. Its just a constraint imposed on time for some reason from which it results an interval, a timeframe, made of a given number of days. Your problem is what you can do best with this amount of time that you have, a problem well put by Gandalf about life in general “all we have to decide is what to do with the time that is given us”.


To escape deadlines we have a quick and elegant solution that is called MVP — minimum viable product. The idea is that you don’t care about the date of the deadline, but only about what can you currently can deliver in that amount of days. MVP teaches that you should only strive to implement the core features that allow deployment, and no more.

The art here is to be able to self asses honestly and clearly. There are situations in which self assessment is hard such as when the team is just assembled and you really have no idea how fast you can do anything. There are situations in which clarity is hard such as when there is no study on the market or customer and you’re working on assumptions. Assumptions are usually false unless they’re scientific theories which are usually false too.

MVP however works very well, even in bad situations, because the theory is sound. As Jon Radoff put it, an MVP is not a minimal product, its a product that is small enough to be affordable and viable enough to be deployed. Affordable can mean a lot of things and it includes: cost effective, timeframe realistic, know how realistic and so on. Deployable can mean many things from saleable to functioning, it depends on what you set sail for.

MVP is not dirty coding hacks to quickly deploy crappy products that nobody will use. MVP is not cutting out features to create undifferentiated offers that nobody will notice. Lets look at the acronym again: MVP — minimum viable product. Minimum means the least required padding that is absolutely necessary around the core of the product. Viable means it has to work for the customer, to solve a problem, to be a scratch for some market’s itch (markets include segments of customers you already have). Product means it has to be self contained, explainable on, the eternal cliche, “back of a business card” space.

The key to implement MVP successfully is to start backwards with it. First of all think about the Product. First of all is it a product? If its not a product you have a major problem because you will not be able to make a project out of it. This tends to be the case with ideas, inventions, generic solutions, avant-garde creativity and weekend projects. Also if the business is up and running consider whether the problem at hand is not customer support, a marketing and communication issue, a bug, a nice to have and so forth. Then do the famous Feynman exercise and try to explain what you’re trying to accomplish to a total noob and see if they get it. As the master of this practice put it, if you cannot explain something to the layman you have not understood it yourself.

So the Product part in MVP means clarity, firm affirmations about what you want to accomplish, why and how is it adding any good to the world (and thereby producing some profit of course, yes even charity or NGO projects produce the so called social profit).

Then continue on this backwards path to the Viable part. Viable means identifying the core of your Product. It is not to be confused with the description of the product! The core is the definition of what is essential to make the Product work. For example, the core of a consumer search engine is result relevance. Its not indexing of data as you’d expect, that is a function that supports the core. The core of a search engine is to help the user find. If it were an exhausting database then, and only then, indexing would be the core.

This then brings us to Minimum. After you have clearly defined what you want to accomplish and found the core of it, its time to identify what is the least necessary support for the core to exist and function. In the not Google example above, a large chunk of web indexed is necessary so that you have something to search into, but minimum means you don’t need the entire Internet, even that not evil company merely searched trough Stanford’s web in the beginning. So one website was the Minimum required to make the core — the relevance algorithm — work.


But having the MVP method in mind and explained lets get back to deadlines. As i said above, a deadline is merely the other end of a timeframe which starts now. There are three types of deadlines: rational deadlines, abstract deadlines and real deadlines.

Rational deadlines are the best kind.

They usually are a conclusion to some sort of plan. Because of that, a long list of assumptions has been made before the rational conclusion has been reached that some deadline is set. Most of these however tend to be too optimistic because people have the bad habit of planning for way too large spans of time. However if the time span is reasonable and the planner capable, its the best type of deadline you can get. Its also the most flexible type because you can adapt constantly to change.

Abstract deadlines come from a need.

Cash flow is most often the need to be solved (there are numerous companies effectively ran by the sales plan), but other types exist as well such as personal reasons of the people doing the planning (fame, promotions, bonuses, bragging rights), dependencies inside programs or large projects (i can’t do this if i don’t finish that — which by the way is an architecture problem not a project management one) and other similar things. These are the deadlines which are probably the most missed in the world and they are the main cause of bad project management. I don’t have a statistics for that but its not hard to imagine the pressure and stress coming from a vague restriction that cannot be properly understood by everyone involved and then the poor results and low productivity rising like a malevolent Saturn in an astrogram.

Real deadlines come from the real world

… and 99% of the time they exist because we use a calendar: events, celebrations, ending cycles (financial, executive terms etc.) and so forth. These are the deadlines that caused most failed products in history (e.g. Windows Vista). Why? Because you cannot fiddle with the placement of Christmas in the calendar or the quarter reporting of a public company. You absolutely have to deploy by that date, and because of that crappy products spawn endlessly.

In managing software production projects you will have a mix of these types of deadlines and this is the exact reason why you should keep the tabs on wether or not you are following best practices or if you have strayed.

Rational deadlines are solved by Agile Development Methodologies because they will reveal your speed and they shorten planning spans resulting in the magical ability to foresee the future (because it gets to be a week away) and take far more rational decisions.

Abstract deadlines are solved by doing Iterative Deployment because they are like a medicine for a health problem, gradually solving it by small amounts of substance. If you’d take the whole amount of antibiotics to solve a bad bacterial flu in one day, you’d have a bigger problem than the flu in the next ten minutes.

Real deadlines are solved by the MVP you put in place. If your MVP is correct, its not a watered down version, a dumbed down deployment, a trick to fool customers in and so on, then chances are you will have it when the event happens. In the case of this type of deadline its important to realize that you actually have a great advantage in that you identified something real to tie your product to as its a lot better to sell or launch when everybody is waiting eagerly than in the enormous noise of a random day. So treat it like an opportunity constraint and mind your MVP.

So, with all that being said, no more deadline dread!