Read this exciting follow-up article by Tech Republic’s Justin James titled: More classic software development mistakes and thought to share the same below.
Whilst Justin’s title and essay might have focused on software development, the listed pitfalls are applicable in almost all project environments – just take out the specific mentions of software and software jargon’s and replace with those used in your industry – and the lessons will come to life for you.
I recommend you read the article on Tech Republic’s website by clicking this link. I have copied the article below (verbatim) in case it is no longer available at Tech Republic.
Enjoy!
1: Not saying “NO”
Ole88 commented, “If a PM or team manager can’t say no, scope creep comes into play too often. You have to know when to say ‘Yes’ and when to say ‘No, that will wait for the next version or update.’” And he’s right! Scope creep can kill a project quicker than you can imagine. It is not justthe added work that is the problem. It’s the fact that the original design never took the new features and requirements into account. It is okay to expand requirements, but the time to implement is often far, far more than it would have been if the requirements had been known up front. This was the top-rated comment on the article, and with good reason!
2: Trying to boil the ocean
A close cousin of scope creep is the “kitchen sink spec” for a project. doug.duke summed it up quite well in the first comment on the original article:
“Many projects are just too big, covering too much scope. In many cases, it is better to move forward incrementally — even within a larger scope of work. Concentrate on getting a well-defined, easier-to-manage set of tasks delivered and bedding down before moving forward with the next. In many cases, massive ‘big-bang’ data migrations fail due to their complexity or end-users simply cannot absorb enough simultaneous change to support successful project completion.”
3: Locking people out of the loop
SpiritualMadMan said, “I just left a software development project after having been told I was not a programmer and [getting] locked out of the loop. Even though my project will be distributed, they will have to rewrite a lot of it because I was not privy to their discussions. And, therefore, it’s not compliant to their standards.”
What a mess! There are often good reasons to not invite ever project member to meetings: It may not be relevant to them, there is always the “too many cooks” issues, and so on. But at the end of the day, everyone in the project should at least be aware of what decisions are being made. I’ve been in similar situations where things were being discussed and I had no idea, and the result was a product that did not meet the secret requirements.
4: Favoring form over function
Long time TechRepublic reader Tony Hopkinson points out that projects often get bogged down in things that are not relevant, and he’s right. For example, unless “make a dashboard” is the project itself, wait until the actual functionality of the application is squared away before you start working on a dashboard. It is easy to get tied up in the minutia of a project when the meat and potatoes aren’t finished.
5: Ignoring those who actually know what’s wrong
neilson brought up this gem: “Failure of management to listen to ‘the trenches.’ This is your classic Dilbert storyline, where management punishes messengers who try to get help for problems that the developers are encountering. An infrastructure to hide bad news from management develops.”
If you think about it for even a moment, you can see how dysfunctional this is. Yet it is one of the most common things to see. Sadly, this is not confined to software development projects, but it is particularly bad on them, given that you are in a situation where mistakes are so costly.
6: Falling prey to responsibility creep
When I wrote the original article, I had a good number of other items that I just did not have room for — and most of those are in this article, after being brought up by readers. But one I had notthought of was mentioned by RMSx32767: responsibility creep. As he put it, “I’ve also seen ‘responsibility creep,’ i.e., a new hire is brought in to work on a specific task then diverted, for whatever reason, onto completely unrelated projects. Needless to say it likely spells DOOM for the original project and its schedule.” Too true!
7: Promising before planning
In an email, Allan P. Clapp reminded me of one of my worst nightmares: the salesperson who says “Yes” to a customer before talking to the developers. This is all too often a path to misery, pain, frustration, and disappointment for both the vendor and the customer. Projects quickly slip behind, as the developers attempt to live up to unrealistic deadlines.
8: Relying on cutting-edge tech
Michael Graziano also sent in a number of suggestions through email. One of them is the habit of developers to use new, unproven technologies on projects, and I have to say that I agree. Programming is a balancing act with this stuff. Do the new technologies convey overwhelming advantages? Will you be adopting a technology right before it drops off the face of the planet? It is an art to pick the right tech, but you can make it easier by not adopting a library that put its first beta on SourceForge last week.
9: Rolling your own
Another point from Michael was the habit of many developers to design and write their own frameworks and libraries instead of buying off the shelf. While there are often advantages to self-made libraries and frameworks, the disadvantages are many. You should really evaluate how important it is for a library to be “just so” before taking on the task of designing, developing, and then testing your own frameworks and libraries.
10: Writing wrong prototypes
A final item from Michael is about prototypes. He related the story of a development team that wrote a prototype of an application in an entirely different system from the actual project. Now, don’t get this wrong, prototypes are good. And in some cases, you can write a prototype in a language or system designed for it, learn some lessons, and throw it away when you are ready to work. The danger is when you put too much time into a prototype but learn lessons that can’t be applied to the actual product you are building.
For example, if you whip up the prototype in Ruby on Rails, learn a lot about database access in Rails, then build the product in ASP.NET, you wasted a lot of time. But if you did the prototype in Rails with minimal backend work, got feedback from users, then put together the real thing in ASP.NET, that makes sense.
Note: Featured image is courtesy of: http://consultantsmind.com
