Seven lies to stakeholders
Those are the points that are frequently subject of misunderstandings or plain misinformation between IT personnel and stakeholders. Encountering one of several of those points in a project is a good indication that communication should be reviewed.
Fallacy: if it works and brings you money, it's a success.
If a project works for now, it doesn't mean anything. The business success at a given moment of time involves a huge amount of factors. An example: as a startup, create a great product, but don't advertise it and don't talk to anyone about it. The project will bring $0. Does it mean that it's IT team's fault?
One of the crucial aspects which play against project success is technical debt. Businesspeople don't see it, and some of them don't even know what this thing is. This makes it particularly dangerous. A project which has a huge technical debt is undoubtedly a failure, since the longer it remains active, the more it costs, exponentially. The fact that at a precise moment, it is sold well is insignificant.
Fallacy: we can deliver all those features in six months.
Learn Agile, dude (or dudette)! The person who takes a risk to deliver a fixed set of features in six months is shooting himself in the foot. Not only estimation is one of the most difficult tasks in development (while being often useless), it's also plainly stupid to believe that the requirements won't radically change during those six months.
If you work on government projects or other projects where months or years are spend doing architecture and design and one of your colleagues leaves, call me, I'm looking for a job.
Fallacy: we, stakeholders, know exactly what we need, and we have all the details you need.
No, you don't. I have worked for dozens of persons and companies and read hundreds of requests/descriptions. The least described ones contained two paragraphs of unreadable crap typed by a drunken guy who tried to describe something he doesn't understand himself. The most described ones contained until fifteen pages of badly-written contradictory stuff nobody reads (including the author himself). Those descriptions were outdated a few days after the beginning of the project, and when they were updated, the updates were themselves outdated at the moment they were released.
Writing a correct WBS takes time. Lots of time. If you've spent years studying requirements gathering and years writing requirements correctly for your new project and you are looking now for a developer, then call me, I'm looking for a job.
Fallacy: writing quality code makes project development slow.
Code is written once and read again and again. Bad code is extremely expensive and hugely slows down the project. If a team of five expert developers may release a given product in four weeks, the same product will take months and months to a team of inexperienced programmers. They may crap something in a few weeks, but then they will spend months and months fixing it. It is not uncommon for the projects to have 95% of the time spent on maintenance, i.e. bugs fixing, given that the cost of this fixing is rarely considered in advance by businesspeople.
Fallacy: we can concentrate at the same time on quality, speed and cost.
The project management triangle is clear. Within a same company, a quick, high quality project requires money. Quality of a quick and cheap project will suffer. If high quality is required but there is no money, the project will be slow.
Then there is productivity involved, as well as a bunch of different factors. There is money wasted, and there are people which are simply not reliable enough when it comes to releasing a project. There are communication issues and management issues. There are internal conflicts. There are weakly evaluated risks. All this can raise or drew the three points of the project management triangle at the same time.
Nevertheless, there is no such a thing as a low cost, high quality project done fast. There are just companies which are
slightlyhugely more productive and trustworthy than others, as well as customers which are more thoughtful than others.
Fallacy: we don't need to automate this; the process can easily be done by hand.
Every repeatable process which is not automated is a source of human mistake. I stopped counting the number of manual deployments, manual updates, manual backups and manual everything I've screwed, sometimes with disastrous consequences. It's not my fault: it's the fault of the process. The more it is monotonous and long, the easiest it is to screw it.
Moreover, when done by hand, a repetitive process is often much slower, and by much, I mean millions or billions times slower. When it's slow, it means that it won't be done frequently. In a case of deployment, it means that there would be no continuous delivery.
I worked on projects where the completely manual deployment can take up to four hours. That's four hours of time somebody could have been spending to do something useful instead.
Humans are bad for repetitive tasks. Computers are excellent at this. There is not a single reason to do processes such as deployment manually.
Fallacy: we're at 90%.
This answer to the question about the progress of the team makes no sense and is usually wrong. The only possible answer a team can give to stakeholders is:
“Look at our board: we've just finished this and that, and there are currently those tasks in our backlog.”
90%-done is indicative of the lack of process and lack of precise metrics of progression. “I feel that 90% of the work is done” is particularly misleading: the question is not about what someone feels, but what is objectively done and what remains. Often, there is a correlation with another feeling: the feeling that a feature is implemented, while it's unstable and was never tested.
Even if the 90%-done wasn't just a feeling, it remains error prone, since it omits one thing: that the backlog evolves. If 900 cases are done in a period of four months and a half, and there are 100 cases in the backlog, it doesn't mean that the team will finish the project in two weeks. It only says that there are 100 cases in the backlog at this moment of time. Nothing less, nothing more. Maybe the stakeholders will add hundreds of cases the next week, or maybe the team will find a serious issue which would result in heavy changes of what was already done: this will result in spending much more time on the project than two weeks. Or maybe businesspeople will decide to terminate the project, in which case the team will spend the next two weeks working on stuff which has nothing to do.
The 90%-done fallacy is based on two mistakes: that one can predict the future and that there is a way to measure precisely what is done and what is planned. Being nothing but misleading, it should be avoided.