Simple^4 Xiaoming Wang

London marathon was held on 26th April 2009 and there were more than 35,000 people participated. Runners dressed up with all kinds of funny costumes, funny as hell. I saw at least 4 spider men, 3 super men, 2 bat men, sunflowers and etc. Of course there were professional athletes, especially women’s game. The winner of 2008, 2007 London marathon, Olympics medalists were all present. Zhou Chunxiu(from China), Olympic bronze medal Olympic 2008, campaign of London marathon 2007 was one of the strongest potential winner who ended up out of top 10. She was in the first group in the first 25km and in very good shape when she passed my front door on Westferry road. Unfortunately she fell behind right after the 25 km point.

There might be a few reasons that she lagged around that point(24 km) where I was. She was not able to pick up the energy drink that was prepared for her and put on a table under a big sign something like “Drink pick up-1″. I guess that she might have moreenergy and get much better result if she was able to pick up that small bottle of drink. I also observed that almost all Japanese athletes had no trouble to grab their drinks. If you look at these two bottle of drinks and read my analysis, you might know why the design of the drink bottle actually matter.

Check out the pictures below (demonstrated by my super model – Dapang ) and find out why the Japanese design is much easier to drink.

So, you see the design of a simple bottle does matter and maybe matter a lot. Think of the design in auto-motor or IT industry, a small awful design might just ruin your potential big success which was established with millions of dollar and lots of hard work.

I recently watched a BBC show called “Dream homes”, that basically talked about how to help people who had problems to decorate their awful house into a dream land within a limit budget. Normally, from the beginning, the house-owners and the show organizers came out a plan, say “budget 80 grand”. When the procurement and  engineering work started, with some changes happening, the budget always went up dramatically to double or even higher. Then they had to give up something in their original plan in order to cut down the cost. Along with the whole program, there were many changes, such as change of the engineering design, “shopping-list”, construction implementation. Sometimes, money were saved and sometimes lost by these changes. This show made me think of our software development projects that included lots of changes every release, every week even everyday. These changes might be initialized by business owners, end users, project managers, or development team. People in this show did not feel like being good at the change management that touched me off thinking about what good practices that we can use in project change management and how to use them.

Insight a traditional project change management approach, a change typically goes through at least 6-7 steps of a process from it is born to its end.

1. Change initiation
2. Change classification/Define
3. Risk/Impact assessment
4. Plan
5. Change approval and notification
6. Execution/Implementation/Test/Monitoring
7. Change acceptance/record/closure

This process made sense to me theoretically, and I did went through several times of the whole process when I was an IT manager in a large organization. It certainly “worked”. However, I observed several phenomena that were either waste or dragged the whole thing to the opposite direction of the goal of the change. E.g.

• People focused on a very detailed plan and it turned out none of the many times of execution actually went step by step following the plan.
• Documentation maintenance was paid very much attention even than the actually the change itself, however two years later, no one actually went back to see any of those documents. I can tell the main reason behind the concreted documents was that people did not want to get into trouble if there were anything wrong concerned the change.

A process/plan driven management approach might caused the above problems. The underline reasons are that human-beings keen to protect themselves and achieve personal achievement firstly if you do not bind their performance with your organization’s value and achievement. However if people could be trained by value/goal driven thinking align with reactive/adaptive project management approach, those problems would be solved.

In a typical IT change project, however it is big or small, going through with the structure of the process is not a bad idea, meanwhile, put too much assumption or make the plan very much details could kill creativity and flexibility during the implementation of the change itself.

Software development project could be a bit different in change management. It is not easy to achieve the same understanding of cost-efficiency of each change, so it normally came to the situation, business stakeholders and development team went for slightly different direction during the implementation of a change. It might be worse, if there was change during the process of making a change. So, certainly it would be very inefficient to go through a whole process every time.

So what would be a good idea? When there was a change that was initialized, team can regard it as a task and put it into development task list, we can think it as a functional task, or defect or whatever it is easy for the team to understand. Then re-prioritize the task list and rank this new task (change). When team estimate the workload of this task, its impact on the existing system need to be considered. Sometimes, it might be just less costly if a change could be combined into some existing tasks that they have similar priority.

People who manage change plan should consider which option could put more business value into the software application and what the goal was to finally achieve. When people driven by value or goal, with a simple plan in hand, they could be very flexible during the implementation, so that the process and documentation just played a helper role rather commander.

Tips:

• Sometimes, business stakeholders and development team could not easily have the same understanding the cost of a change. In this case, splitting the change into several tasks could make it easier to understand.
• Use any chance such as meetings, daily catch up, project Wiki to communicate with the team about the changes that would be made and notify every sponsor and stakeholder.
• IT need provide enough information for business to understand the cost and impact of a change and co-work to make a correct decision.
• Make a change plan more goal-driven and not too detailed so that team can be more creative during the implementation.
• Communicate more if it is possible, maybe development team can demonstrate a completed task that was not the complete change to business, so that team can check if they were going to a correct direction.
• Risk and impact assessment is necessary however it does not need to be very formal or be written as documents.
• The closure of a change should be able to be demonstrated in the real application.

Back to the beginning, if the house-owners could manage their changes in this way and well prioritize their task list and considering any change as one of task, their job might not be that painful, they might just get a fairly dream home.

Dot-com bubbles

Challenge of IT industry

Real economy need IT innovation

So what shall IT do to be prepared for the coming spring?

Successful projects

There are varied criteria of determining if a project is successful. They are

• Maximize the business value of project delivery
• Deliver on time
• Achieve the quality of the project(product/working software)
• Achieve the margin, reasonable the benefit
• Customer’s satisfaction
• The team well developed and enjoyable
• Good relationship with client
• Reputation in the industry
• and etc

It is not too difficult to define and work towards those objectives in the beginning of the project. However, two months later, how many projects were still considering the set of goals is what they were working for? Many teams only focused on several of them. If you were asked the question, why did you give up some of them? The answer would be very simple “No time!” I can not blame the excuses because the crucial judgment of a successful project is “Deliver on time”. The reason that we did not achieve all the goals in the end of the project is that we regard them individually, not looked them as one OBJECTIVE. And the even worse, team member might understand the goals differently, and work towards different directions. You might find, some objectives were partially accomplished. Partially done work is also considered as waste, even effort was hard made. Personally, I don’t reckon that a successful delivery is always the top one criteria to measure whether a project is successful. However, it is mandatory.

So how can we ensure that the whole team works towards the same goals, keep going and accomplish them in the end of project. You need GOT and GDT.

GOT stands for Goal Oriented Thinking; GDT stands for Goal Driven Team.

In general, we need the whole team think the project in a way of “Goal Oriented” and the project team should be “Goal Driven”.
It might be quite dry to understand the concept and where to start. Let me give a start point, thinking of the reasons of failure projects.

Reasons of failure projects

The reasons of failure projects vary case by case. They could be

• Customer’s expectation is beyond team’s capability
• Contract is much risky
• Requirement changes too frequently
• Lack of communication and feedback
• Team does not have the same goal
• Team does not focus on the goal
• and etc

Nevertheless, if the team does not work towards the same direction, the risk would be much more increased. Sometimes, project managers felt quite frustrated that the project failed even they had the money, right people and kinda nice customers.

Behind the reasons, either the team did not have the same goal, or did not work towards the same goal. So how to organize the team to achieve the same objectives along the road of project and make a project successfully? We need GOT and GDT.

GOT (Goal Oriented Thinking) & GDT (Goal Driven Team)

In order to make it more clear and transparent to my readers, I organize my thinking into five aspects(In pink). In each of them, there are solutions(In green) and tools(In yellow) to achieve the objectives of “GOT and GDT” through the whole life cycle of a project. Several solutions can also map to our daily business activities(In blue).

There are also relationship between Solutions, tools and activities. For details of this diagram please view here.

Goal Oriented Thinking

In the beginning of a project, not everyone in the team might know what exact goal of this project. So first thing, a project manager need to do is to figure out “Goal for small and big team” and clarify them, put them in a place that is visible to the whole team all the time. Then a PM still ensure that all effort which the team makes is for the goal of the small and big team. PM is responsible for drafting and finalizing the goals. I will talk about this in the “What a manager/Lead should do”section. Sometimes, you work in a small team which is part of a big team. PM need to let everyone in the team know the goal of each team. In most of the cases, small team has more goals than the big one. Make sure to balance them across teams. Team member could have objectives for himself. Make sure PM has the interviews before you draft the goal of a team, considering their personal objectives and balance it. After a goal or set of goals is finalized. It becomes the goal for a whole team. So It is OUR goal but for individual. One team One Dream.

Goal Driven Team

When you have a team which has the same goal. Next, make sure team member continue working to achieve it. To build a GDT, first thing, let everyone in the team understand it and ask them how they can do to help the team and himself to achieve the goal. PM can make it as several action items for teammates every other week. Then in the end of each two weeks, PM can evaluate individual performance against goal/value. It is not a good idea to have a performance review in the end of each year. Because no one would actually remember what a team member did well or not. Why not divide them into each very small trunk and evaluate them.

A pull system is a good tool in order to achieve the goal for a team. After we have action items for individual, you don’t have to push tasks to them, all you need do is get the tasks ready and ensure its visibility. Team member will self-organize to pick up tasks in order to accomplish team goals and his personal action item.

To build a GDT, PM should make sure that you get the right person on board. If anyone who always have different understanding of the team’s goal or can not work towards it. He might suit for the other projects but this one. A PM need to recommend him to another team or resource manager in this case.

An organization has her own visions, objectives and targets. Our ultimate goal is to align the team’s objectives with organization’s vision. Only a Goal Driven team can make this easier.

Transparent Team

Even, a GDT is right there, we can not take for granted that a team will never change. Team member need to know everything in the team. The team shall be transparent to all sponsors, customers, users and team member himself. It does not limit to visibility of the plan, progress and risks but the business plan. Why business plan? If a team member does not know it, he won’t know how valuable his effort is. If team member don’t know it, he would not know whether what he is doing is waste.

Another thing, every project need pay more attention to, let the team see the whole system but his individual area.There are several tools that we can use to help. Business process diagram of the whole system is always help. Each small team may highlight his own part.

Sometimes, developers focus on individual functionality/story, rather than the whole business process or the system itself. In the middle of project, some team keened to make large amount of code refactoring. There are many reasons that lead to the smell situation. One of them is that developers don’t see the design for the whole business process or system. The diagram here shows how stories map to the business process. Why not hang this diagram somewhere everyone can see it?

For project plan and progress reporting, I recommend several tools, such as “S-curve”, “Burn down and burn up Chart”, Kanban or story wall and task wall

What we did was not enough. 10 minutes technical knowledge sharing should happen everyday. One minute talk is another useful tool for the team to practice communication skills. We can do more. Get the lessons learnt visible to the whole organization and require feedbacks. Open discussion, more communication helps the team more transparent.

At the same time, the team has the reporting material for senior management team. No extra work is needed. Someone said that “Reporting is only for bosses”. Not all true! Bosses need see what is going on in each team, meanwhile every team member need know this as well. They should see the same page.

What a manager/lead should do

I have been talking about what a manager/lead should do in the previous sections. Personally, I don’t like separate managers and leaders into two groups. Nowadays, managers do not only control schedule, control cost and etc, we also set directions, develop resource, align people and Enable motivation.

First thing, a manager should do is to draft and finalize the goal for a team. So what is the goal composed of?

• Contract and deliverables
• Margin of the project
• Individual career development
• Organization vision
• Customer expectation and satisfaction
• Team’s enjoyableness of the project
• Business development’s strategies
• Reputation
• And etc

This is how a project goal composed. Think of its balance and compromise then, explain it to the whole team, answer questions and reach individual’s understanding.

PM and the whole team need to highlight the goal in any occasion, such as meetings, activities, requirement discussion and etc. Whenever you observe an activity that violates the team’s goal, anyone should stand up and let the people know that they might be going to a wrong direction. The team shall consider those behaviors as waste and eliminate them right away.

In summary, project manager need focus on removing road blocker, providing any possible service to the team and at the same time guiding the team to a correct direction.

For HR team, it is a good way to measure people’s performance referring to if individual worked for the team’s goal and how much value that each team mate contribute .

Goal is not everything

How do we deal those good ideas that are not associated with our goal?

Please don’t ignore or throw them away . Offer another place for those good ideas and encourage the team to develop the ideas into a real thing in non-project time. I always believe that the innovation is the key of successful business.

Summary

In summary, combine the goals of organization, project and individual into one GOAL, as OUR goal. Help the team to work towards the same direction in order to achieve the same goal which will make you a successful project and successful business.