Ministry of Technology
Show Menu

Optimising Project Delivery - Feel the Pain

Optimising Project Delivery - Feel the Pain

This is my fourth article in my series of optimising project delivery in an agency environment. I have covered fostering positive conflict, adapting the resourcing model and blockers. This time around I am going to look at the principle of feeling the pain.

Feel the Pain (and do it differently)

This is a central enabler of change within a business and is dealt with by most agile methodologies to some degree or another. The theory is that, if something goes wrong with a piece of work, be it technical, management or organisational or if you are regularly suffering from blockers coming from the same source then you are being exposed to pain. Pain, in it's physical form, is your body telling you not to do something. If we view the team or organisation as a body then exactly the same thing applies. If you are caused pain then you should try and avoid the circumstances that led to that feeling.

Can We Change?

When a team finds itself suffering from a pain point the first question they should ask themselves is whether they are able to deal with the issue directly and make appropriate changes to avoid the situation recurring. If so then action should be taken and evaluated over time to see that the issue has been resolved.

We Can't Change But...

If a team finds that it is not in a position to deal with the issue that is causing it pain then the team should liaise with the rest of the business to locate where the issue can be resolved. The business should then, depending on the issue, either empower the team to be able to deal with the issue or adjust the processes between the affected team and the team that is in a position to deal with the issue so that the pain is felt by the team that does have the capability to fix it and change accordingly.

An Example

To highlight this, let's look at a simple contrived example and follow the logical process through. 

  1. A client of the agency contacts their representative in the customer team and asks that the footer of the website be changed from their old company name to their new company name.
  2. The customer team puts together a task for the development team. The task reads 'Change the footer of the 'Our Customer' website from their old company name to their new company name'
  3. The development team gets the task and begins work on it, quickly noticing that the new company name is not provided.
  4. After several hours researching online the development team locates the new company name and makes the change.

A relatively simple task that could have been performed in less than an hour has taken up to 3 times longer than it could have done. The development team evaluates this performance and logically determines the following...

  • Is there anything we can do directly to mitigate this in future? - No.
  • Where did the issue come from (from our perspective)? - The customer team.
  • How can we reallocate the pain of similar issues to the customer team to enable them to ensure these issues do not occur in future?

The development team liaises with the customer team to determine solutions that place the pain points of this issue with the customer team to improve efficiency and an agreement is reached whereby tasks with inadequate information will be rejected and sent back to the customer team.

This reallocates the pain to the customer team so the process flow then runs slightly differently if it happens again...

  • A client of the agency contacts their representative in the customer team and asks that the footer of the website be changed from their old company name to their new company name.
  • The customer team puts together a task for the development team. The task reads 'Change the footer of the 'Our Customer' website from their old company name to their new company name'
  • The development team gets the task and rejects it immediately, sending it back to the customer team.
  • The customer team contacts the client to get the required information or spends several hours looking through the internet to complete the task before passing it back to the development team.

The task has still taken longer than it should overall in the same way as it did before but, this time, when the performance is evaluated it is this time evaluated by the customer team and the logical evaluation is different...

  • Is there anything we can do directly to mitigate this in future? - Yes.

The customer team determines that they can prevent these issues occurring by reviewing information with the customer when taking info down for a task before they pass it on to development.

The customer team now have a new metric by which they can measure their performance by looking at the percentage of tasks that are accepted by the development team.

 

Summary

By applying this logic over time you maximise the flexibility of the organisation, making it as reactive to change as possible and foster an open inter-team communication environment where all parts of the business can see that they are pulling in the same direction.

What Next?

In my next article in the series 'Optimising Project Delivery' I'll be looking at the importance of minimising the process separation time between creative work and QA to maximise both quality and profit.