Project Management

10 ways to avoid mistakes during project development

The best strategy for dealing with mistakes is to avoid making them in the first place. Here are some tips to help you navigate around common project pitfalls.

The best strategy for dealing with mistakes is to avoid making them in the first place. Here are some tips to help you navigate around common project pitfalls.


You may have heard the phrase "Be proactive, not reactive." It's certainly appropriate when discussing how to best deal with mistakes. The idea, of course, is to prevent mistakes before they occur. But how exactly do you do that?" In this article, I will detail 10 real-world ways you can preempt mistakes during project development.

For the sake of simplicity, I've lumped all errors into one category: mistakes. The items listed here are specific to developers, but other IT roles can also benefit from many of them.

Note: This article is also available as a PDF download.

1: Learn from other's mistakes

Find experienced peers who are willing to share their mistakes and then learn from them. I am somewhat biased, but the editors, writers, and members of TechRepublic seem willing to honestly share their mistakes -- even if somewhat embarrassing at times.

2: Do your research first

No matter how much you know, you'll encounter new challenges on an almost daily basis. Each challenge usually requires you to learn something new. Before you tackle a problem or task, do your homework. The trial-and-error method of learning may have been necessary and acceptable years ago. But with the resources available on the Internet today, there is little excuse for mistakes made because you didn't do the proper research in advance.

3: Have a plan

You can't know how to get to your destination without a roadmap. In project development, that roadmap is known as a project plan. Whether done formally or informally, you need to know how to get where you are going. Days or even weeks of programming time can be lost if the wrong path is taken. When done the right way, a project plan will help keep you from straying off course.

4: Follow standards and use templates

There are good reasons why experienced professionals took the time to create and publish industry and company standards. Standards detail best practices and procedures learned over years of trial and error.

Templates such as predefined forms can be useful since most of the work is already done in a standard format. A standard EULA approved by your legal counsel is another good example of a template that can come in handy if you are developing application software. A mistake in a legal document can be an expensive exercise -- one best avoided.

5: Communicate and coordinate with others

If you are part of a team, it's essential to communicate with other team members to avoid redundancies and to coordinate your work with theirs. Emails, instant messages, project status reports, and teleconferences are all ways to communicate and coordinate with others on the team. Unfortunately, each of these is far from perfect. You can spend the better part of a day reading and writing emails, participating in conference calls, and instant messaging with your peers. But it is a necessary part of the development process.

The perfect tool for communicating and coordinating with others in a team environment has yet to be developed. One of the better tools developed to share code is revision control software. Your project may also benefit from the use of a communication plan that ensures everyone involved -- including customers and stakeholders -- is kept apprised of key developments. (The TechRepublic downloads library has a free communication plan template to get you started.)

6: Allow enough time

It was at Hughes Aircraft Company that I first heard the phrase "You want it bad - you got it bad." It didn't happen very often, but when it did it was almost always made in reference to a part from a vendor that was badly needed, rushed through production, and upon arrival, failed testing. Failure to allow enough time for each phase of the project can lead to missed requirements, inadequate analysis, poor design, rushed programming, insufficient testing, and incomplete documentation. The result can be a system that doesn't meet expectations and fails in one or more key areas.

Estimating the time needed to accomplish each phase of a project is difficult. I achieved the best results when I sat down with my supervisor and determined the time allotted for each major task in the project plan. I was overly optimistic in my estimates. He was much more realistic in his estimates, and he turned out to be right. As a rule of thumb, doubling my initial estimates came close to the actual time required. That information was useful for developing project plan timelines.

You may need to develop a similar rule of thumb until you can more accurately estimate completion dates. Ideally, you want to complete each phase of the project on time, and the best way to do that is estimate them correctly up front. Here are a few tips on creating realistic schedules.

7: Reuse proven code

If you're an experienced developer, you should have built up a large code base over the years. Go blue and recycle this code whenever possible. You will likely have to modify the code to fit the new requirements, but proven core code is a good foundation to build on. Not only will you reduce the risk of introducing new bugs, but you will eliminate the time wasted creating similar code and the subsequent testing required.

Share your code with others so they can reuse parts of it. Proven code can be shared via plug-ins or libraries. Good external sources of code are available on the Internet that can be legally used for free or for a small fee.

8: Use checklists

Before a commercial plane trip, the pilot and co-pilot are busy walking through a long, detailed checklist. Checklists can be used during various phases of the project development process. They are particularly useful when working with large systems and when a single person is responsible for multiple tasks.

For example, a list detailing the steps required for system turn-on will help avoid accomplishing tasks out of order and prevent errors of omission. It is all too easy for developers to overlook important items like system access when they are busy doing final testing and documentation.

For more on the virtues of using checklists, see Leverage checklists to improve efficiency and client satisfaction.

9: Test, test, test... and carefully review your work

There is a healthy level of paranoia about delivering error-free work. Test as much as possible as early as possible. Errors in the code are typically more expensive to correct when found near the end of the development process. The last thing you need when facing a critical release date is to find a bug that should have been found months ago.

Careful and thorough testing will allow you to find those mistakes before your users can. Double- and triple-check your work. Develop test data and a plan to test common calendar-based events like EOM processing and annual reporting. All functionality and every single possible scenario should be thoroughly tested. And, yes, this is also a good place to use a checklist.

10: Test again with a third party

Find at least one experienced person who can be dedicated to the beta testing. They will undoubtedly use the system in ways you never dreamed of and find bugs you missed.

Don't overlook or rush this final quality assurance task. It's typically your last chance to get it right. Once a bad piece of software is released or a system with a critical bug is turned on, a company's image can be tarnished for years to come.

The final word

One of the most important lessons I learned very early in my career is that a mistake isn't a mistake until someone else knows about it. I was but a young inexperienced pup when I accidentally deleted some system files on a Tandem PC. It could have been a disaster. But I had enough sense and problem-solving skills to identify and copy over the missing files from another Tandem PC.

I have never told anyone until now about my near disaster. This may be obvious, but you should keep unseen mistakes to yourself. There is almost never anything to be gained by telling others you have done something really stupid. It can negatively affect your image and possibly damage your career.

I hope these proactive tips will help you avoid making an embarrassing mistake that becomes known to your boss, peers, and users. If you find yourself in that unenviable situation, you might want to read Calvin Sun's article 10 things you should do if you make a big mistake.

I have always learned the most from my mistakes -- but I prefer not making them in the first place.

Additional resources


Check out 10 Things... the newsletter

Get the key facts on a wide range of technologies, techniques, strategies, and skills with the help of the concise need-to-know lists featured in TechRepublic's 10 Things newsletter, delivered every Friday. Automatically sign up today.

About

Alan Norton began using PCs in 1981, when they were called microcomputers. He has worked at companies like Hughes Aircraft and CSC, where he developed client/server-based applications. Alan is currently semi-retired and starting a new career as a wri...

22 comments
deepakdabas
deepakdabas

Good article. All 10 ways mentioned are very effective and practicle. Specially proper and thorough testing with good collaboration among team members helps a lot to deliver good product.

shawn46
shawn46

Regarding item #1 Why would I want to learn from mistakes - I would rather learn from successes - I see a lot of Project Groups, Sales Team, and corporations analyzing what went wrong instead of what went well.

Alan Norton
Alan Norton

... credited to Henny Youngman - http://www.funny2.com/henny.htm Patient: "Doctor, it hurts when I do this." Doctor: "Then don't do that!" And then there is the saying in basketball, "No harm, no foul." I see that there are a lot of you who think I should have shared my mistake with others. The two words "really stupid" and the fact that the mistake was fixed before it could be noticed are the reasons why I felt no need to share my mistake. I could be wrong, but I could see nothing to be learned by others: Alan: "I deleted some system files on a client's PC." Boss: "Don't do that!" I agree 100% that if others can learn from your mistakes you should consider sharing it. I would classify how to handle mistakes into three categories: 1. The mistake becomes known to others and fixed - Read and follow Calvin Sun's advice at http://blogs.techrepublic.com.com/10things/?p=270. Take responsibility for your error and try to make something positive out of a bad situation by helping others learn from your mistake. 2. The mistake is not known to others, fixed and others can learn from your mistake - Consider telling others so they can learn from your mistake. It's your choice. You have to weigh any benefit gained against any personal damage. Sharing too many mistakes can be item one on your next performance review. 3. The mistake is not known to others, fixed but there is nothing to be learned from your mistake - It might make for some light humor (he did what?!) but what else is there to be gained? It is even more unwise to share your 'mistake' with the client. No harm, no foul. We all make dozens of 'mistakes' a week that we find and correct. I used to have to participate in a teleconference call at one of my jobs. It usually lasted 45 minutes to an hour. I can't begin to imagine the litany of mea culpas if everyone on the team decided to share every little mistake. In fact, I don't remember anyone volunteering to share any of their errors, big or small. I do however remember the big mistake I made and I am happy to share it with you here. I submitted a request to reindex one of our database's indexes. The request was queued and never ran because, unknown to me, the reindexing could only be completed when there was no user activity. By the morning, the entire system was locked up and yours truly got the opportunity to step forward, take responsibility and explain what I had done to everyone on the conference call. I am encouraged to hear so many of you say that you should take responsibility for your mistakes. I totally agree. I just don't think that it is wise to share every mistake and, in good conscience, I can't recommend that you share a mistake made in scenario two or three since it could damage your career with little or no gain. That has to be your choice.

Englebert
Englebert

A sophisticated manager understands that people make mistakes. We're all human. Now, two things have to happen : 1. The mistake has to be fixed. 2. The process that allowed the mistake to occur has to be fixed. And communicated to all. Chances are if you made that mistake, others could have as well. So, the experienced manager calls a meeting and explains it to all.

jalexan
jalexan

If you watch the TV show "House", you know that many of his miraculous cures come when he discovers the client's lie. Same is true in IT Projects. Few clients know the real issues, so they tell you only part of the truth. Your challenge is to uncover all the issues and build them into the plan.

karl.werner
karl.werner

You had me going until the "Final Word". While you should immediately resolve your mistake, in the efforts of fostering your very first point, you should be willing to relay and even laugh at your stupid mistake. How wrong would it be if a colleague made the same mistake you did because you were too embarrassed to relay your mistake to them???? Finally, I've always said: "If you are an active developer (and haven't moved on to other responsibilities), you should be able to look back at the work you did a year ago and see ways you could have done it better, even if what you did a year ago was quite good. Otherwise, what have you learned in the last year?"

nicola_gambetti
nicola_gambetti

Even you're talking about a product (project development, may be a system), you've described the ITIL V3 Foundation core (IT Service Management): V model, communication policy, Catalogue, RFC approve after CAB, etc etc. That's great, because ITIL has bourned as good practices after a long research about IT best practices inside various world businesses. You can also express in this way: even you're an IT professional don't think to be the only in the universe fighting against a big project; be honest, take your time, share ALL in a trasparent way, learn from and collaborate with others (not only IT); in this way the goal will be yours. Isn't it?

Bgovindsamy
Bgovindsamy

No matter how stupid a mistake may seem, it has a lesson to be learned behind it. Furthermore, is a questions of honesty and integrity for owning up on ones actions. I am a PMO manager for a large multinational mining organisation and would like to sleep easier knowing that our team will homour the code of conduct and professional responsibilities. Sometimes "stupid mistakes" can cost an organisation millions- chances are, mitigation actions can be drawn up sooner if more info. about a problem is known upfront. Just think what would now happen to the "google buzz" test team if they had known about the privacy issues and "bugs" in buzz and not reported it. Bigger picture - consequence such as those sighted in the conclusion of the article can be attributed to environments with low maturity and/or emotional intelligence.

ogils
ogils

Surely item 2 should be first!

lknox
lknox

Checklists are a must. We all need to recognize we are busy and often interrupted. Let the checklist be our memory.

Tony Hopkinson
Tony Hopkinson

Can't do 1,they read your final word and won't tell me. :D Accepted wisdowm is good, but don't take it at face value. It was right then, for them, with those. The one constant is change, don't ignore it to avoid thinking. Have a plan, yeah right. Remember the plan was a hope, a wish, a fiction to provide an illusion of control. If the illusion breaks down, your wish is not granted, your hope shattered on harsh reality. Change the damn plan, and plan better netx time. If the plan wasn't followed there was a reason, and it could be that the plan was crap. Just because your boss made it, doesn't mean it's right, in fact if you were not allowed to contribute to it, it probably guarantees it was complete bollocks. Create and adapt standards and templates to meet your needs then follow them, until they don't help, then adapt them again. Poor choices are as bad as none at all. Revsion control is a mechanism for sharing already written code. The key communication is why it was written and why like it is. Group think sessions are my favourite tool in a team, get a consensus in approach, document it, institute a frame work based on it, use it specify the immplementation detail. Revision control is bog all use until you know which piece of code you need to look at. It's major purpose is an audit trail, a back up (assumimg you remembered to back up the host!) and a way of rolling back in the event of a bad idea. Trial and error, or more likely suck it and see is a perfectly acceptable way to learn. Even if research turns up some "answer", you still have to find out if you asked the right question. Identify unknowns, work on knowing them. Then expect what were unknown unknowns to now be unknowns. Iterate towards comprehension, instead of waiting for it. Allow enough time. You must be new. Time is set by the business, they want it yesterday, that's how long you have. Don't whine about it being impossible they don't give a crap. Reuse abuse is one the biggest failings in software design. Remember as soon as you change it, it isn't proven anymore. Remember common code solves a class of problem where required and could cause one everywhere it is. It's not a free lunch. Checklist are just another standard or template. A decent one particulary for admin style tasks. Keep them up to date though. If the step has gone remove it, if there is another add it. If in certain scenarios a step is ambiguous, document it. Plan so you can test right from the get go. Every confirmation you are on track has value. Test after you've gone too far down it, is a lot of luck and bugger all judgement. Identify your deliverables, define key properties of them. Plan a test, do the work, do the test, then take you next step. Unit test, autmation test, sanity checks, peer review, dedicated testers, a demo version, a key customer who might trial it in the real world, damn straight, do all of them if you can. I've made lots of mistakes during my career. being creative requires mistakes to be made. Fear of error means you never get better, which by definition in a constantly changing environment means you are getting worse. Sometimes they can turn out to be more useful than successes. Don't plan to make no mistakes, plan to minimise the consequences WHEN they happen. If you aren't making mistakes you aren't trying. I give the way to make less mistakes doing anything. Identify assumptions, and review them constantly.

Alan Norton
Alan Norton

If you have additional ways to avoid mistakes, please share them. In item 2: 'Do your research first' I note that the trial and error method of learning was more prevalent in the past. I always enjoyed solving problems this way but it sure took a lot of time and there were the inevitable mistakes along the way. The Internet has become such a wonderful source of information that even inexperienced developers can solve complex problems simply by learning how to best use search engines. Fortunately not all solutions can be found on the Internet. I say fortunately because good problem solving skills are still required - and problem solving is one challenge that every good developer truly enjoys.

Tony Hopkinson
Tony Hopkinson

So I got out the backup... Oh there was no back up, or it woudn't restore, or those files weren't on it, or you couldn't extract just those files... Well there's the real coke up then! The fact that you manually deleted the files is irrelevant. A programming error could have done it, A power cut, a lightning strike, pour your coffee down the cooling vents. A hard drive failure or corruption. Your 'mistake' was fortuitous! Learning it from it, is not "don't do that again". It's that your client was a clock cycle from disaster, is a clock cycle apparently, since you didn't ameliorate the risk in any effective way.

B
B

I agree, I'd much rather have people realize a "stupid mistake", own up to it, but most importantly LEARN from it. Then I know there is growth and integrity!

mialp
mialp

Alan - that was a clever ruse to get us writing replies! I had posted the following before reading the further article and I will willingly admit my error! I couldn't agree more. Hiding mistakes is a disastrous idea with potentially disastrous consequences. A project leader needs to foster a culture where people will admit their errors, no matter how stupid, and learn from them. In the example how could the writer be 100% sure that the new files he copied were exactly the same as the ones he'd deleted?

Suresh Mukhi
Suresh Mukhi

I agree. Unless Alan meant that the "mistake" would have no harm done, which is very rare.

Alan Norton
Alan Norton

Ha ha! Very clever of you! Normally I don't put the '10 things' items in any particular order. For this article it made sense to order the items to match as best as possible the Project Life Cycle. Maybe I should have put item 2 first!

nils2myklebust
nils2myklebust

You forgot the most important. Do your design first. In our agile world so many forget that. It is possible to design excellent software. You, as most everyone also over emphasize testing. I have started to say "don't test - design". Of course that is a little rhetoric, but there is a lot of truth in it. You should write correct code that does what it shall do all the time. You do that by designing first, creating a simple design document that will be thrown away as soon as you have finished the first release version. Then you write a few lines of code, execute, a few more lines, execute, and you know it's correct. Of course this is testing :-) But the aim is to understand exactly what you write and that it's correct according to a design. Then don't listen to users! They are not software designers, and can not design the code, not even the user interface for you. There are a few exceptions for user interfaces with exceptional users, but otherwise you have to do the design. To do this you have to listen to your users! But not to do what they say they want, but to learn what they really need and then deliver something better than they expect. The wow effect is close, but it does require a lot of work. To be a professional developer you have to know better than your users their requirements and needs. You can only do that by learning from lots of different users by communicating with them and studying their profession more then they do. Lots of work, but your aim is excellence and nothing less is possible.

Involve real users in prototype testing at early stage development.

Kim SJ
Kim SJ

That's been an adage of ours for all our working life. What it means is that what users see on the surface has to be a good match for what they say they are looking for, but what exists underneath has to be well engineered, future-proof, and covering all the cases the users have not even though about. The "mistake" is implementing what the user asks for, without engaging your brain.

Editor's Picks