How to Deliver a Successful Project – Part 5 – Delivery: Communication is Key

Posted in: Blog, Methodologies, Project Delivery | Jan 12, 2013 at 12:08 PM

No comments

INTRODUCTION

This is a series:

Part 1. What Does “Successful” Mean?
Part 2. Start It By Defining THE Business Requirements
Part 3. Accurate Estimates, Quoting and Proposals
Part 4. The Project Plan and Work Breakdown Structure (WBS)
Part 5. Delivery: Communication is Key
Part 6. Managing Changes
Part 7. Project Closure

DELIVERY: COMMUNICATION IS KEY

This is the part where we are in the process of delivering the project. In software development term: the coding time. From my experience to ensure a successful delivery, communication is key. What does communication mean? Communication means that everyone related to the project (ie. the stakeholders and team members) is up to date with the progress of the project.

Communication encompasses a lot of things:
– You and the stakeholders: use weekly progress report and weekly meeting to track project
– You and the team members: use weekly meeting and daily timesheet to track project
– Your team members: Use task list and source control application such as TFS or sub-version to communicate with each other
– Your team members and the stakeholders: Use bug tracking application
– Using email to summarise any verbal conversation that may have impact on the delivery of the project
etc

But what I’m saying is, communication is the essence of a successful project delivery. I have been in a lot of clients where communication is not clear. Again, I’m talking more than just a casual chat or daily coffee break between the team (ie. words conversation). I’m actually talking about processes and tools that you can utilise to ensure that everyone is up to date with the progress of the project.

The main goal of communication is:
– Everyone is up-to-date with the progress of the project;
– No single thing related to the project is overlooked and missed;
– No surprises arise (ie. “Oh I forgot to mention that I’m taking a 1-month annual leave next week”).

So let me break communication down into several categories.

You and the Stakeholders

Communication needs to be clear between you and the stakeholders. We want to make sure that the stakeholders know how the project is progressing. Therefore, if there are some issues or delays, you will not be in trouble. The best way to communicate with your stakeholders is through quick weekly progress meeting and weekly progress status report. Unless it’s a designated meeting for demo, do NOT demo anything otherwise you are creating a room for scope-creep. Your job is really just to report to them how the project is tracking and if everything is still on-track for the deadline.

The weekly progress report is also very handy. The progress report contains the following information:
– What has been achieved this week
– What is going to be achieved next week
– Any potential risks

You and the Team Members

Between you and the team members communication needs to be flowing. You need to know how everything is going with your team and recognise if there is a potential risk or delay. Do a quick weekly progress meeting with your team to see if everyone is on track and if there is any potential issue (eg. Developing JQuery script takes longer than expected, etc).

You can also follow a particular development methodology. Me personally, I use Agile development methodology but outcome-based instead of the one-or-two-weekly sprints. If you are not familiar with this methodology just look in Google there are tons of information about it.

Use technology if you can to communicate with your team such as bug tracking, task list, etc. I personally use Team Foundation Server (TFS) because in it there is already a built-in bug tracking, task list, etc.

I also often send jokes and buy my team members coffee just to lift the morale of the team. Remember, they are the ones doing the ground work so you need to make sure that everyone is top notch – as far as morale is concerned.

Between Your Team Members

If you are doing hands-on work yourself, use technology to communicate between yourselves. Again, source control repository such as TFS or SubVersion is very important to ensure that everyone is sharing the same code and no one works at the same file at the same time. It also helps maintaining the version and integrity of your code.

Make sure that you also have a shared folder for tools and software downloads so everyone in your team has the same tools installed and no one is left out.

Send jokes among you. It helps in keeping the morale high.

Your Team Members and the Stakeholders

Give your stakeholders access to your bug tracking system so that they can report bugs during UAT.

Give them some test cases so they know what to click and test.

NEVER allow the member of the stakeholders contacts the team member directly otherwise communication can be interrupted and things that are mentioned to your team member may never get exposed to you (hence introducing room for scope-creep).

If you want to give stakeholder member access to your team member, that is fine but you have to educate your team member to ALWAYS DOCUMENT the conversation in an email and CC you and the rest of the team members.

You, Team Members and Stakeholders

As mentioned above, ALWAYS document every verbal conversation that may affect the progress of the project. I’ve had one of my client’s stakeholders came to me and said, “Tommy I think it will be good if you change the color of the links to red”. Although it’s a 2-second job but if I didn’t document it and I changed it, then the rest of the stakeholder members didn’t like it and asked me to change it back to blue and I said to them, “But Bob told me to change it to red” and Bob said, “Sorry, I didn’t recall telling you that” then you’ll be in trouble.

Identify changes in the conversation then document it in an email.

You, Team Members, Stakeholders and the Rest of the Business

Once the software is ready for deployment, communicate with the rest of the business by letting them know ahead of the deadline that a new software is going to be implemented. It’s like on the road where I see a sign saying, “Next week the road will be closed for Iron Man event”.

By you communicating with the business ahead of time, you are also indirectly creating an anticipation. People in the business will be looking forward to use the software.

Use positive words in your communication such as: “We are going to roll out a new HR software next month. This software will allow you to work a lot more efficiently because you will be able to submit timesheet online”, etc.

CONCLUSION

There are tons of other things that you can do to ensure communication is flowing but if you can do the above at the very least, you are doing really-really well.

The project is only doomed to fail if conversation is not clear.

No Comments Yet.