Failure Is Not An Option, So Focus On Goals!

May 12th, 2009

Download article in PDF

Five Key Reasons Why Focus on Goals Is All That’s Needed to Achieve Success in an IT Project.

Do you ever wonder why your IT project is not achieving the desired results? Do you think proper attention to management will lead to success? Or that using the right architecture frameworks, methodologies, and technologies are key to success? Why do IT projects incorporating a lot of management attention and state-of-the-art methodologies still under-deliver, run out of budget, and finish too late? Because these projects focus on too many things other than what really matters: the goal.

  1. Only the sponsor and the end user are concerned about the goal
  2. Have you ever watched a soccer game where the players showed the finest form in ball handling, with superb passes, but no goal was scored during the entire game? And did you like the game? Most likely you felt disappointed. You won’t say bad things because you love your team and you know they will win in a future game. Or lose. But without focusing on the goal, the team is not likely to become a winner in the long run.

    With IT projects, as in sports, it is no different. Who cares what technology you use to implement the system? And who cares if the vendor has a strong alliance or preferred partnership with the leading hardware or software brands? I am not suggesting these are unimportant matters, but they don’t deserve the focus. The end user’s only concern is that the new situation will allow him to improve. The sponsor is interested only in achieving a return on investment. This goal should be clearly defined and communicated to everyone.

    In one example, an organization was dealing with five multiple non-compatible operating systems, three different email systems, and two network protocol stacks. The system administrators were screaming from pain. Their managers pulled their own hair. They all went to the CEO, telling him, “We have to do it differently.” So the CEO asked, “What should we do?” They came back with answers like, “Convert all non-Microsoft Exchange email users to Microsoft Exchange.” “Let us implement the file servers with Novell’s Netware and use the naming convention from Acne division.” The CEO asked them what it would cost. When he added up all the numbers, he almost fainted. He could not imagine asking the board for this amount of money. In the meantime, the cost of maintaining the IT infrastructure was more then double the average in the industry. And people within the organization didn’t know how to send emails to someone not on their system. Nothing really changed until the discussion was shifted to the goals to be achieved. Then the CEO, who had appeared reluctant to give up his email software, was more then willing to change to a standardized choice.

  3. Discussing status quo is talking about the past
  4. People love to discuss what they have and how they feel about it. But this is like looking at photos: you always look at something from the past. This is all fine when you want to recall fond memories, but of no use in going forward and making changes to improve the situation.

    Consider again, for example, the email system. People were describing how feature-rich Exchange was. How well messages were integrated with calendars. And how you could send messages from applications running on the desktop to notify other applications and people. Of course, there were also drawbacks, but those were considered technicalities. And details—to be solved in the next release. What would be solved in the next release? Nobody knew. So we had a discussion in the past about the unknown future. Like gazing into a crystal ball.

  5. Focusing on tasks is no guarantee that the desired result will happen.
  6. Not everybody is gifted with a great vision. A goal may be so far away that some people don’t know what to do. A natural habit for those in charge is to give these folks assignments. Every project manager is trained to divide the project into tasks and assign them, even debating for hours the best task size for a given project, and the skills needed to perform the task. But do we really know what results will be achieved when someone starts on a given task?

    Allow me to demonstrate this with a true and remarkable story. A knowledgeable person was in charge of implementing a new directory. He discovered that 30% of the approximately 1,000 users in the directory had an attribute set to a wrong value. On the plus side, these users were all part of one group. So he had to correct the value, but he couldn’t find the function in the management user interface to change this value for the whole group. Made sense: it was not a group attribute. He looked at programming a tool to make this change, but discovered that it was not supported by the Application Programming Interface (API). He also spent some considerable time investigating this problem with the manufacturer. He got an answer we hear so often: “Maybe in the next release.” He reported back to the project manager that there was nothing more he could do. His final suggestion was to email each of the affected users, telling them they had to change the attribute themselves—only five mouse clicks. Unacceptable, of course, but it struck a nerve. Every mouse click in Windows can also be achieved using the keyboard, a feature often overlooked. So the program manager went to see an administrative assistant with excellent typing skills. It took her less then 15 minutes to make all the changes, during which time she ate her lunch and made three phone calls. And she wasn’t even on the team.

  7. Focusing on people doesn’t motivate them to achieve something
  8. You have probably seen or heard mottos such as “People work, solutions don’t”. What should we focus on? Skills? Talents? Activities? Scores?

    A classic example is the ranking list in some schools. Those at the top feel they have achieved something. We are not sure what, because all we really see is that they are on the top of a list. The rest feel even worse, because they are not seen by others as having achieved anything.

    What really moves people toward behavior change is a new situation that is an improvement for themselves. Everyone looks at his or her own actions with one question in mind: “What’s in it for me?” Once someone knows that for himself, he can also feel good about achieving it. With this focus, you will discover that your team is filled with people improving their own situation. Consequently the team’s situation is also improved. And here you will find that 1+1 is a lot more than 2.

    I don’t mean to make it sound easy. Managers must often motivate people. Once you understand that you can’t fix people (and thus their motivation), but that you can fix causes by creating the right conditions in which they can thrive, significant progress will be made.

  9. Track progress in terms of the goal, to prevent disasters
  10. You probably heard a famous saying, “What you can measure, you can manage” (the McKinsey Maxim). This doesn’t imply that you should measure everything to track progress. Measuring is necessary only to see if we have achieved our goal. Tracking anything else is interesting for statistics or research, but it won’t help you at all to prevent disasters. It’s like cooking food using the smoke alarm.

    In one example, system managers were asked to test the system after modifications had been made. The managers felt that because the outcome of the test was not as expected, the test was wrong. And since the test was considered wrong, it hadn’t taken place, and hence there was no need to report it. When reporting test status, the system managers produced only a list of successful tests. This list wasn’t always very long, so when asked if they had reached the goal (a recoverable system, expressed in hours to recover after disaster), the answer was, “We don’t know. Before the modification, we didn’t know, either, if the system was recoverable.“ It turned out, they had never tested the goal.

    With a clear goal, everyone is in a position to report “distance from” the goal. While moving toward the goal, someone can reliably predict when the goal will be reached. Asking for a report with this in mind, people will probably move even more quickly toward the goal. There is no need to set up some formalized reporting structure or format. You don’t even have to look at the report. Ask questions regarding achieving the goal. You will be amazed at what will happen and at the results achieved.

Conclusion

Focus on the goal, the outcome, the result. That focus needs to be in every communication, discussion, report and meeting. People will start to look in the same direction and move toward the goal. Any other focus is essentially a waste of time.

Want to achieve success with your IT project? It doesn’t have to start at the top. It can start with yourself. Ask yourself: “What’s in it for me?” Set your own goal. Communicate with others how your goal aligns with the end result. Ask other people involved to do the same.



Bookmark this article on:
del.icio.us | Digg it | Furl | Google | Technorati | StumbleIt | Yahoo!