geordee.com

Value Addition

Howard Artrip - a manager in Toyota - knows what he does. He knows when he gets up, how long he takes to get ready and get to work. He smiles when he says "I've maximized my sleep time". Toyota's philosophy of continuous improvement is his personal statement.

Sometime back, I was talking to an engineer from a highly capable and mature company about what he thinks about quality. At the end of a very colorful description about the practices and processes, he confessed that it is difficult to follow them all. It was a burden on him, and in his opinion an overhead to the system.

It is a fashion to adapt and implement the processes and techniques that are proven in some organizations. In a frenzy to implement and report the return-on-investments, most managers fail to get the spirit - and most importantly the thinking - behind these processes. One of the common mistakes is that we try to replicate the processes without understanding the context and culture in which these were set and became successful.

Value addition is the promise of most processes and techniques. At the end of the day we search for added value in the process, in the end-product, in the pile of documentation, reports, and presenations. What I find often is that we miss out in searching for the added value in our people. It may be that we think they are just techies or skilled workers, we think they appreciate the processes themselves, we think the processes have nothing to do with people and vice versa!

People need to understand the reason behind every activity, the benefits and a bit of history to enjoy their work. It is important to infuse the spirit behind the process into people, so that value is first added to them - and they realize it. They will in turn add value to products and even back to those processes.

Well Begun Is Half Done

It is a very old saying of Aristotle - well begun is half done. We find this true in many fields, especially when it comes to accomplish a certain goal - whether it is in studies, sports or projects.

We have developed and mastered many techniques and processes to execute a project. But we deal with project initiation with a bit of laxity. In the height of dramatic events involved in realizing a project, we sometimes fail to see the fine cracks that are being developed - in terms of missing out details, under-estimating functionalities, setting aggressive timelines etc. It then becomes a fight for the team to hold the project from falling apart during its course to completion.

It is good to estimate, and it is better to re-estimate. There are many techniques which are developed to encourage multiple estimates - quick/detailed estimates, optimistic/pessimistic estimates, low-confidence/high-confidence estimates and so on. It is also important to work out estimation parameters from the final estimate that is used to win the project. One aspect which is overlooked frequently in estimation is dependency. The project dependencies normally drive the schedules and idle-times and it is crucial to understand it early on. A good work-breakdown-structure can solve this easily.

It is also good to create a visual representation of the project and its environment, something like a map. Words can be hazy; numbers can become tough to follow; visual representations are easy to comprehend and remember. It is good to note that all military operations start with a study the area to be conquered, usually represented by a map. It is good if the project map includes not only the deliverables, but also other details such as schedule, size, assignment, risk etc.

Training and team-building are some aspects that are taken lightly. It is important for the team to understand the terrain - environment, existing systems, work-flow, domain knowledge, business rules, tools, techniques, limitations of technology - before starting a project. Building a knowledge-base is a best-practice in most of the execution frameworks. The earlier and faster we build it, the easier will be the project execution.

If we take Aristotle's words literally, it is fine to devote half the project duration just to initiate. If you are worried about a possible time-crunch, return to some past projects and see the productivity during the last few weeks.