We all live in a world of projects, roles, and methodologies, from the basic to the complex. It’s how things get done in the team-based world. I have played many different roles over my 17 year IT career from Developer to DBA, then Analyst to Project/Program Manager and now Enterprise Data Architect. Many times I was playing multiple roles at once. In the world of projects my personal success does not necessarily guarantee project success, but my personal failure can doom the whole project. So I have devoted my efforts on identifying several key pitfalls that can cause even the best projects to fail and I have identified a few areas to focus on to ensure that you can get over these pitfalls and be successful in your project role(s).
Pitfalls: The Slippery Slope
Pitfalls are anything that can cause a widespread problem to your project and they live on a slippery slope, make no mistake about it. Allowing one of these things to go unattended can cause a cascading effect that will ripple through your project like a shock wave.
- Limited/No Communication
Having limited or no project communications can be the easiest way to kill a project. A team that doesn’t communicate well is prone to misunderstandings…which leads to assumptions…which leads to confusion and dissatisfaction…which leads to rework…which leads to missed deadlines, overspent budgets, frustrations, and on and on down the slippery slope. And it isn’t just communications with your customers that are vital, but communications between the team members themselves to ensure everyone is doing their expected tasks. If you have to start asking questions about a team member, such as “Where are they?” and “What are they working on?”, then you are going to have some problems which again lead to mistrust, confusion and dissatisfaction.
- Poor/Missing Documentation
All too often, documentation is an afterthought. Something that someone reluctantly puts together after completion because they were asked to. I suppose it’s easy to document by reverse engineering because you basically just write down what’s there…..but what you’re missing is how much more difficult that project was to complete because there was no guidelines or directions. Think about it this way: Go to IKEA and look at a dresser. Just a basic one with 4 drawers. If you were standing in front of it with a piece of paper, you could easily write down its specifications and how it is put together. Now, buy that dresser and take the box home. Open it up, only to find there is no instruction manual. Go ahead and take the 28 pieces of wood and metal and the dozens of different screws, bolts, and pegs and try and put it together to make it look like the one in the store. Could you do it? How long would it take you? How much quicker and easier would it have been if you had the instruction manual? That is what the team members downstream of you face when you don’t document your requirements/expectations. Without a document to reference when questions arise, we most often are left to assume or trust our memories (which, if you’re like me, can be both comical and dangerous at the same time!). Remember this: “Guessing” almost always means “Rework”.
- Change Requests
Depending on the timing and the nature of the change request, it can be a piece of cake or it can be a nightmare. Think about adding a new field to a screen from the same underlying table versus changing the source of the screen fields to a completely different data source. And even with the former, it still depends on when that request was received. Are you still working on that screen? Or is it done, tested and delivered already? Your current project methodology also dictates whether or not “CR” is a 4-letter word. Projects done in the Waterfall method are not very conducive to change requests, especially after a phase has already been done and signed off.
- Churn, churn, CHURN!
Do you ever get sick of your inbox being flooded with “Oh, and can you do this?”…. “As long as you’re there, can we get this too?”, and “I thought we had agreed to do this….”? How are you expected to close anything out and move on to the next task when you keep getting pulled back into things you worked on weeks or months ago? Constantly changing requirements can cause a lot of churn, and so can all of the questions and issues that arise from any of the other pitfalls we have discussed above.
So, How Do We Get Over These Pitfalls?
There are two key areas that everyone on the project team can focus on:
Ambiguity occurs when things are vague or unclear. You’re leaving things up for interpretation and everyone knows the perils of what happens when we “assume”, so do everything you can to remove this word from your work. Not just the things that you send out to others, but the things that are sent to you. If something you’re given is unclear, ask questions until it isn’t anymore. How can we remove it?
- Make sure that any scope/work items are listed out. Bullet points work great here! They’re much easier to read and quickly decipher than having to go through paragraphs.
- Remove the ambiguous language in your documentation. Replace every “should” type word with “will” or “shall”. If you say that “The user will click on the ‘Save’ button and the application should save the record to the back-end database table”, does it fail the test if it doesn’t save?
- Track any questions you have as issues. It doesn’t have to be anything too formal….put it as a task in Outlook if you want, with a reminder to follow-up. If someone or something is holding you up, keep on them until you get your clarity.
- DOCUMENTATION – No project is too small to benefit from some documentation. You don’t have to go with a full BRD, Functional/Technical Specs, Master Test Plan, etc. At the very least document the scope of your efforts, the design you created (save comms/e-mails for reference), and the methods you are using to develop it. Include drawings, diagrams, and charts if you can. Like most people, I’m a very visual person and it’s so much easier to convey information that way. Plus, you can use a single chart/graph to represent what it would take pages of text to do. But whatever you do, get it down on paper. It’s not just a great communication tool, it’s a great method to CYA.
- “KISS” over-engineering goodbye. You’ve heard the adage, “Keep It Simple, Stupid”. It’s no truer than in software development. Just because something is new or fancy doesn’t always mean it is better. Other people may not be up on the latest and greatest, so you’d be creating something difficult to understand and maintain. Third-Party tools are another way to save time and effort (usually), but they come with other factors like licensing and support costs. Are they worth it? Maybe. Maybe not. And reuse code modules where you can. Why spend the time writing something that’s already been done. Finally, include good comments in your code citing the logic and intent, and include references if applicable. Here is a great example:You see that I have properly commented the code to describe what it is doing. Note the filter on the bottom row, where it says “al.IsBillable = 1”. That filter came out of a business requirement given by “Cheryl and Michael”, so I made sure to notate it that way. To anyone who might look at this code down the line, they will know why the filter was put in and who asked for it so they can follow-up if they want more information.
Properly Managing Expectations
Managing expectations is about making sure that everyone is on the same page regarding what you are doing and when you are going to be finished. This applies to every task and every resource. As we’ve gone over already, there is a myriad of things that could affect and/or delay a project, so properly managing expectations means that there are no surprises at the end of the road and no one is leaving the table upset. Here’s a couple easy ways to do that:
Using this method, designs go through “stages” with a 360 degree feedback loop. This allows developers the chance to modify the design, as needed, before implementation. It also allows the customers to better understand what is being delivered and to get their feedback in time to be able to make any changes.
- Project Communications
Frequent meetings and/or status updates are a must. In-person is great, but online works too (especially if your team is spread out). Getting together on a regular basis allows people to stay in touch and on the same page. Having a project “portal” is key as well. Some place that you can store the project documents, communications, etc. and make them available for all of the team members and stakeholders. Most common is SharePoint or Confluence, but you could also use TFS, PowerPoint, Excel, and even e-mail! The point is to be able to easily get people the information they need on your project.
- Project Dashboards rock!
I’m a huge fan of dashboards because they bring all of the relative information together and provide a visual status report. Instead of having people poring through pages and pages of documents, they can glance at a screen and in 10 seconds know all of the key information they need. Here is a great example of how you can use colors and summaries to give a comprehensive overview:
In summary, every project is going to face challenges and every team member will encounter hurdles along the way, no matter what role(s) you are playing. A single person can’t ensure that a project will succeed, but they can ensure that it will fail. You can maximize your potential for success if you focus on removing the ambiguity from your work and properly setting expectations with your team. You’ll be surprised at how easily these efforts trickle down to other team members and how much smoother your projects will go. Best of luck!