Communicate Early and Often: Real Lessons for the entire Team!

I’m often asked, “What’s the one thing that makes the difference between a successful project and a failed project.”  In my honest opinion, the success of a project comes down to communication.

Yes, there are all sorts of other things that can make the difference between success and failure, but I think the root of most of those problems comes back to communication.  You can diligently move through the lifecycle or through your sprint, you can create all of the project documentation and artifacts that you want, you can create pretty gantt charts to show the team, you can track all of the money spend and forecast future expenditures, you can track all of the defects and their remediation plans, you can check off all your milestones, however, none of that will make a difference unless you are communicating properly up through the project hierarchy and across the project team.  And, yes, there are two very different communication paths – each seeking their information.

The first path is the tactical path – cross communication between the people responsible for the day to day activity within a project.  These are the hands on people, making the product, building the processes, and changing the way things work.

The second path is the governance path – communicating up through the management chain to the sponsor.  The sponsor is the owner of whatever is being delivered, and ultimately owns the decision of whether to keep on working the project, rework the project if the results aren’t up to spec or to abandon the project.

Both communication paths are critical and if team members don’t support the communication strategy – you’ll be doomed to failure.  Don’t get me wrong, you might ultimately get your project into production, but you’ll have spent more money and your timeline will most likely have suffered due to rework, or you’ll have delivered the wrong thing.  And you’ll know it when people avoid using what you’ve built or it quietly gets shoved into a trash can somewhere along the way.

Let’s start at the beginning …

Who’s the Sponsor for your project?  Are they clearly articulating the vision?  Are they controlling themselves and others as it relates to scope?  Are they plugged into the project?  Do they know the major risks and mitigation strategies?  Do they understand the overall budget and do they know if the team is on track to meet or beat the budget?  Do they give guidance when the team is up against an obstacle that they can’t solve on their own?  Do they clear the roadblocks in front of the team? 

Or, do you find yourself learning new wants/needs every time you say hello to the sponsor?  Are they ignoring the risks the team has identified?  Are they unattached – do they really care about what is going on in the project?

What about the Project Manager?  Is your Project Manager setting expectations up front?  Are they letting you know how often you’re going to meet as a team?  Do they do frequent stand-ups to get the quick status checks?  Do they communicate regularly and update you on the status, risks and mitigation plans?  Is the Project Manager holding people accountable to deliver what they said they would, when they said they would?  Is the Project Manager tracking against the budget and keeping the Sponsor in the loop?

Or, does anyone actually know who the Project Manager is?  Did they set clear expectations for the team at the beginning of the project?  Did they communicate who owns what pieces?  Did they explain how often you would meet and what the format of the meetings would be?  When was the last time they talked to you about the pieces you own?  Do you know how the other pieces of the project are coming along – will they be ready when you’re ready?  Is the Project Manager out removing obstacles and ensuring that you can stay focused on your job?  Is the Project Manager providing you the details you need to know whether the overall project is on track?  Are they ensuring that decisions made are being distributed across the entire team?  Is your Project Manager checked out?  Do you see the Project Manager only when something is going wrong and they want to point the finger and redirect the blame?  Is the Project Manager in reactive mode only dealing with issues when they become critical?

And let’s not forget the team members – are they keeping everyone in the loop on the most recent changes to the schedule?   Do they immediately notify team members and the Project Manager when they see a risk that might affect the project down the road?  Do they escalate an issue when a vendor is not delivering functionality within the timeframes identified?  When they identify an issue, do they also provide potential solutions to resolve the issue or catch backup on the timeline?

Or, do they ignore the entire team when they have hit something unexpected?  What about when a requirement changes, any notice from the BA?  Whoops, did that interface change?  I’m sorry – didn’t you know that I won’t have that done?  Oh, that decision on the pricing has changed, didn’t you get the update?

None of this is rocket science and it doesn’t take someone with a masters or a doctorate to figure out what the issue is.  Get up out of your chair walk down the aisle, take a right and let someone know!  Use your scrum meetings to share issues/concerns with the team.  Let them know when something has gone off track.  Instant message the Project Manager – trust me, they want to know.  Pick up the phone and let someone know that something in the market place has shifted and the sales projections need to be updated.

Part of being a team means that you’re making some commitments – these are not optional:

1. Be accountable for the work you are supposed to complete.
2. Listen to other team members in project meetings – that means you won’t be checking your email or browsing the internet.
3. Be an active participant in project meetings – interact with team members and move the ball forward.
4. Share your knowledge with other team members – lift those around you.
5. Provide a regular status – you need to agree on what regular means.
1. As a team member that may mean daily.
2. As a Project Manager that may mean weekly to the Project Office and biweekly to the Project Sponsor.
6. Immediately communicate risks or issues with mitigation plans as soon as they are known to the Project Manager.
7. Immediately notify the Project Manager and other team members when you know you’re not going to be done with your assigned piece on time.
8. Be a problem solver – when others identify issues, be willing to help find solutions.
9. Be flexible – we all know things change, be the one to find the way to address the change.
10. Be respectful in how you communicate and interact with others, be supportive when needed.

I’m not saying this is going to fix everything that is wrong with the projects you work on.  I am saying it will make things go a lot smoother.  We need to trust each other enough to be open and honest with each other.

Tags: Project Management; Software Development Lifecycle; Teams; SDLC; Change Management;

For more information on David L. Collison: LinkedIn Profile