In the same sense that the greatest NFL coaches never have a perfect record season after season, you will have some projects not go perfect too. Over the years I have observed some lessons learned on ways to put your project at risk.
 

1. Too much process change early on.

     If you are new to your company, and you want to make your mark, it is really easy to see inefficiencies in processes and want to fix them right away. What happens is that while you fix the inefficiencies in the process, it actually slows down the processes in the short term while new processes are put into place and people get acclimated. A few different forces are at work here; First, you have not gained the respect and trust from peers to support your changes, and second, process change generally mean that relationships among the people that it affects are changed too. This can create a state of confusion until the new relationships work out their kinks. In addition, being newer to a company means you will have a tendency to miss some inner dependencies and subtleties of the existing processes.

Lesson Learned:
Observe for a while. I would highly recommend not changing a single process for at least 2-3 months depending on the size of your organization. Identify a few key people and get their input and consensus on how to improve the inefficient processes. Introduce changes a little at a time when possible, but communicate the end goal so everyone understands why the changes will be beneficial in the end.
 

2. Switching to agile development because it sounded cool.

     A few years ago agile development was just becoming popular in the mainstream. If you read about it you would think it solved everything. It doesn’t. Switching from a waterfall cycle to a more iterative cycle actually causes more chaos than helps when it is first implemented. It also changes peoples roles. For example in an agile process the role of the business analysts changes dramatically. The analysts no longer spend weeks of up front time making a pretty document. Instead they must collaborate daily with the developers and help get clarification on items with much more frequency. If you try this major change on a fresh new project with a fresh new team and expect everything to fall into place after a few training sessions, you’ll be wrong.

Lesson Learned:
Iterative development processes such as “Agile” and “Extreme” are a beautiful thing under the right conditions, with the right people, and with the right culture. If you do not have all the right pieces, slow down a bit. First decide what problem you are trying to solve, by changing your methodology. Then have your management decide how the change will affect each role. Also decide how communication will change and what tools will be needed to support the iterative process. And last, ease into it by trying the process out on a smaller non-critical project and work your way up to more significant projects while adjusting your approach along the way. Every organization needs to decide what works for them, and not blindly try to follow some strict set of rules outlined shiny agile process manual.
 

3. Not recognizing management/stakeholder hot buttons.

     Does your management want a successful project or is their real concern to keep the senior stakeholder of the project from storming into their office once a week with complaints on how he feels left out of the loop? Subtle point here but sometimes a project is perceived as failing based on some key persons being upset, some minor feature not making into the release, or some other non-core functionality not being what someone though it was.

Lesson Learned:
Communicate a lot. Don’t under estimate the power of relationships. Set up a channel for all people affected by a project to be able to voice their opinions to you or the Project manager. What does success look like to them for this project? The key to this is getting measurable goals if at all possible to remove subjectivity. The other key is to ask for lots of input at the beginning stages to insure their is a clear vision and goal and then to slowly start closing the gap as the project gets into full swing. Although you should always be open to minor adjustments and input along the way, sometimes it is better to wane the input slowly as the project nears completion to prevent a never-ending-project syndrome from occurring.
 

4. Not communicating project statuses early and often.

     As a larger project matures it begins to take on a life of its own. Side meetings sometimes begin to take place, initial communication channels sometimes get side-stepped, and its real easy for a part of the team to get bogged down on a few essential items.

Lesson Learned:
Insist for your project managers to establish some mechanism where people can get an overview of the current project status, its current challenges, and recent milestones. Stay away from the dreaded percent complete as a status since it is really a meaningless term. Saying that you are 70% complete done with a project that has been going on for about a month, does not really tell anyone when the resources will free up and when the project will be complete. Instead have a status include items such as upcoming milestone start and end dates, man days to complete, and constraints that are known. .The goal of this “dashboard” view is to not sugar coat anything. Tell it like it is from day one and everyone will be happier! I often encourage keeping a wiki of some sort that lists the goals for the week and the status on the goals from the previous week. Those weekly goals should then role up in to the goals for the month or quarter depending on the size of the project.

5. Resolving issues with Naysayers head on.

Any major project that begins has naysayers. Change always puts people into 3 camps. The folks that are for it, folks that are against it, and folks that are indifferent about it. The goal is to not have any folks that are against the project on the project team. In the real world this rarely occurs, so the next best thing is to confront the naysayers head on.

Lesson Learned:
Do the naysayers have valid reason to be against the project that are being swept under the rug? Have they been listened to? Is their issue with the project personal in nature and not really about the project at all? Whatever the reason, these people will become the largest cancer to your project if the issues are not addressed swiftly. Sometimes the naysayers are good company people that have valid concerns and need an avenue to be listened to and their thoughts validated. On some occasions these naysayers can be turned into the most passionate go-gutters on the team.

6. Taking on too much in one project.

     It’s common for managers to want to solve the world as fast as possible. Many people feel that when fixing an issue you might as well fix two or three other items since your in that are anyway. Its a noble idea, but in technology this is often a slippery slope where fixing two other items forces you to fix two other items and the path continues.

Lesson Learned:
Always strive to take a divide-and-conquer approach when possible. A project that appears to be 3 months long has much less risk when it is broken down into three one-month sub-projects. Not only does it force the managers to think at a more granular level of the solution early on, it also allows the team to correct issues at a much earlier stage in the project. I usually insists that tasks are never more than one week in duration. If they are longer, then I ask for a further break down of that task. The larger the project, the less feasible it is to lock down the scope. Change requests will happen, so insure all parties understand the risks, trade-offs, and affects on the timeline from each change requested before deciding to take on that change.
So there you have it. Six lessons that seem like common sense in hindsight that I have personally witnessed over the years. I hope some of these lessons-learned might help you on your teams’ successes.