From the minute detail, up to the bigger picture.

Communication is key with any project, and knowing what each of the other team members is thinking and doing is the aim of that communication. To that end, agreeing on a common process helps to avoid misunderstandings and gives everyone a good idea of what should be happening and when.

 I’ve had experiences where two people sitting opposite each other have developed applications in completely incompatible ways due to a lack of communication. One coded his application to accept priority values of 1, 2, 3 and 4, while the other coded it to accept the values Low, Medium, High and Critical. Either would have worked, but they didn’t work together. If they’d spoken to each other more, or had it in their process to review what the other one was doing, then the problem could have been avoided, or at least spotted much earlier.

 Hopefully you’ve already got a high level process agreed for your team – if not, then think about creating one. Focus it on your own responsibilities, and then map out what you need to deliver, and what you need delivered to you from other people in order to get those done.

Most importantly, get those who deliver to you, and those who receive your deliverables, to agree to that process; only then can you be sure that it’s right. Resistance to the process will be expected to a degree, but it can also mean that the process needs to change. Remember the following:

a)      Encourage feedback, and develop your process accordingly.

b)      Don’t set it in stone; allow it to change as business procedures, roles and responsibilities do.

c)       Allow some flexibility. Projects rarely go completely according to plan, and your ability to react and adapt will determine how well the project copes when things go wrong.

d)      Remember to use the process once you’ve got it. Pin it on a wall or keep it on your desk. Don’t go to the effort of setting it up and then forgetting about it. Once people have agreed to deliver or receive, then hold them to it.

Again, keep all the above in context. Processes for a simple update to the news page of a website aren’t as critical as those that control the next major product launch.

 As you go on, you’ll find that there are many activities that benefit from having a documented process. The overall project is the obvious one; however further down you will have processes for the testing approach, and then the defect management process, the test reporting process etc. Having these defined and documented saves time that can be better spent on finding more defects!

Advertisements