Posted by: James Murray
when relevant content is
added and updated.
In planning a project, one must look at scope, resources and time. Seattle IT consulting experts in my area often focus on the technical execution of a plan. The other aspects of the project are ignored. I think this means that we are undercutting ourselves as technical consultants. So I created my Technical Collaboration Outline as a help to try to sort out what I was missing in my ball of string
What I found for myself was that I wasn’t planning my projects well enough. It turns out the technical execution is actually a very small part of the project. As the project becomes larger and more complex, the non-technical aspects of the project become more and more important to consider. Planning a project for me is like setting up dominoes. When you push the first domino each of the following dominoes falls next. So with the energy to push that first domino dozens, hundreds or even thousands of dominos will be affected.
Taking the domino analogy one step further, in a project no all dominos are the same color. Some are black, some are blue, some are white and they all need to be ordered in the right way. It turns out that planning the project is much more important than the execution itself.
We’ve all been on projects where suddenly the dominos stopped, even though here are dominos still standing. What happened? On domino in thousands was ignored so it was just a little to far away when it fell. This meant it missed hitting the next domino. If you’ve been on a project like this, trying to start the next domino in line becomes a real problem. Now the project team is putting out fires. Fires that probably never should have started.
Sun Zhu taught his leaders to plan everything in their headquarters not on the battle field. What I find with most projects is that there are some fires that couldn’t have been anticipated, but 90% of the time fires on the project are a result of poor planning. To avoid fires I add what I call governance roles into my planning. An example of a governance role can be seen all over business. The controller is a governance role for the CPA. The Human resources department is a governance role for the employees. The board of directors is a governance role for the CEO. When IT departments and technical projects fail, I’ve found it’s because we don’t plan any type of governance role into the project. Among my partners, I always try to assign a business governance role and a technical governance role. The business governance keeps the project on track and makes sure no roles are getting side tracked.
The technical governance role allows me to verify that my technical experts are being honest with me. We’ve all seen technical experts who use their technical expertise as a way to consolidate power. Adding technical governance negates that power. I use technical governance to hold my technical experts accountable on a project. I put the governance piece in form the beginning so everyone is aware that that can’t shade the truth in any way