Project Heroes

Every project has its heroes. I am not talking about the pompous grandstanders selfishly getting their fingers into every process in order to gain fame. I am talking about the people that really get the work done. Toiling tirelessly to complete their tasks and move the project forward. Below is a profile of seven of them. I have chosen them because they represent agility, communication, responsiveness, and cooperation. These are the traits discussed in my last article.

I have picked them from a longer list of recent project participants so they span the breadth of the customer-supplier relationship. This sampling is a cross section of disciplines providing each of us with something to think about on how we carry out our duties. It presents a small study in how people perform their jobs while their infectious enthusiasm inspires the team.

To be a good business analyst you need to be analytical and earn instant trust. This allows you to dissect the fiercest of business processes and present an unbiased view that allows people to make decisions. Ms. Brown is all this and more. Her smiling, gracious nature befriends everyone. Her answers are clear, complete, concise, and correct. Both direction and criticism are taken with an eye on how she can improve or help others improve. She understands her workload and gets tasks completed in the time frame she initially estimates. People are confident that her answers are objective and untainted with by her views, opinions, or filters. She now uses these traits as a Project Manager.

John Halseth, Customer Representative

The customer is the most important part of the project, without them there would be no project. However, customers often fail to understand that there are limits on what can be delivered. Mr. Halseth is different. He understands the meaning of give and take and its direct relation to success. Understanding what is actually needed in a solution is difficult; it requires leading a team to make decisions on the real importance of features. Remembering eighty percent of the value is in twenty percent of functionality elevates this customer far above the rest. He looks for the right solution, realizing that stubbornly sticking to a single solution is the recipe for failure.

Working in an operations center is tough. If everything works right people forget to thank you since smooth working operations centers are invisible. Response and stability are paramount. Mr. Huang understands the importance of stability, configurability, and consistency. While working in Taiwan with teams of non-native English speakers, I was always confident that he knew what I was saying. He takes active listening to new heights. From the direction he is given, he provides a sample of the preferred solution with all the pros and cons listed so that there is no question on what is being built. He works day and night to make the systems work by the deadlines needed. He coordinated his peers and communicated with a wonderful sense of humor—good luck doing that cross culture.

Being junior on any team is tough. Being a junior analyst transitioning into IT is even more difficult. Some junior people, Ms. Hudgins included, are so cautious about making the normal mistakes beginners make, that she underrated herself. The first team she worked with me on, her lead did not trust her. However, she was a finished diamond waiting to be removed from the box. She needed to be trusted, this would build her confidence to complete any task she was given. As I reduced the involvement of her lead on the team, I told her, "I have more confidence in you than you do. Go make it happen." All she needed was to shrug off the newbie bias. She has blossomed into a premier analyst.

Most top-notch programmer/architects know they are and it shows in how they deal with people. Condescension is the norm. Mr. Lemmond is different. He codes circles around others, develops designs, produces documentation for others to follow, and works with management to get designs to fit into the budgetary and time constraints of the project. He is a coding beast and a team builder. He sets his sights on a goal and achieves it. He never needs managing, although at times he needs to be asked to slow down.

Quality Assurance has immense pressure. It is the last hurdle between building and deploying and no one enjoys stopping the delivery. Mr. Litvin has a way of making this painless. Honest and open communication of the issues with a proactive way of working with developers and customers ensures the problem is properly defined in order to verify the failure is real and the fix is correct. It is not just the product that needs to be validated; the tests also need to be complete and correct. Redundant tests only slow the process and frustrate the team. Mr. Litvin sees what makes sense and cuts out the fat. When QA has completed their tests, they get the dubious honor of running them again. Mr. Litvin faces it with a smile.

Translating a large project's needs into infrastructure solutions is challenging. Virtualized environments help, but the cross-task coordination is still a nightmare. One needs to be proactive and aware of the subtleties of multiple projects at one time. The fact that there are multiple projects contending for the same hardware only make Ms. Nibbler smile at the challenge. As an IT infrastructure project manager, she anticipates and balances needs between the development and maintenance teams. Her cheery attitude, effervescent smile, and ability to pull people together, are only a few of the powerful tools at her disposal. She exhibits fantastic agility being able to change direction on a dime, with her team in tow, making them feel happy to make the change. She queues up people and resources getting them to a point where changes can be made in the last minutes before they is required. The infrastructure appears magically.

What Makes Them So Special

These people have many traits in common from needing minimal management to their ability to see the big picture. Their communication skills are described in superlatives and they only complain when they have a solution to accompany the concern. They are model team members and we can all learn from them. However, the true differentiator is their cheery can-do attitude and their humble approach to their exemplary capabilities.

Commemorate Your Own Heroes

Please add your own project heroes, in a comment below, including what makes them so special.

Related items

Process is at the core of any business. It makes work predictable, repeatable, and transferable. Without it we cannot scale our businesses. However, process can be a bane to making progress. Processes that work for a $10 million company have difficulties supporting a $30 million company. Trying to scale them to a $300 million company will not only fail but not address the issues that larger companies have that were never dreamt of in a smaller organization. Processes need to be discarded, revamped, and built—all of that without creating an overburdening bureaucracy.

Anytime you need to go someplace, you first have to know where you are. Processes are never static and your company's current state is probably far from where you think it is. Hence, the first step is mapping out you company's current state followed by defining the future state. This is more than a logical map of the process; it must also include physical maps. Whether your process is solely to provide a service (say, website development) or physical (say, manufacturing) there are logistical issues that complicate the process flow. Without fully understanding those nuances, future state processes will not reach the desired efficiencies.

For more information about process mapping fill out the form to the left and we will get in touch with you.

The other day a Latvian student contacted me for my views the connection between culture and success criteria—an important and intriguing topic. After working in Taiwan, Singapore, Korea, Japan, Israel, United States, and Canada, I wear many scars of both blatant and subtle cultural violations. I also know that within a culture one person's success is often another person's failure. So, after dispelling concerns about clicking on some random email link, I completed her survey (please feel free to take it yourself). In the process, I struck up a friendship with the student, Kristine Briežkalne, who is studying at Riga International School of Economics and Business Administration . She has some interesting views and presented me with a Venn diagram showing four frames to a project (business, client, project management, and growth perspectives) and how they intersected. As the diagram is part of her Master's thesis, I will let you ponder the how to label the overlapping areas (an eye-opening exercise).

There is a reason we do not teach classes on fixing failing projects. Many a cynic feels that we simply do not want to teach our trade, however, our reason is far nobler—we should be teaching prevention rather trying to create white knights to save the day. It is the same philosophy as building a fence at the cliff's edge rather than an emergency room at its base. Our language is replete with idioms telling us to look past the symptom and address problems at their root cause. 'An ounce of prevention versus a pound of cure' or 'a stitch in time saves nine.' Please, feel free to supply your own in the comments. Unfortunately, most of our businesses loathe this philosophy, waiting to address an issue until it is irrefutably broken.

A few weeks ago, I set out to write a post on the comparison of various organizational change management (OCM) methodologies and realized that would be a disservice to my readers. It would simply drag you down the path of implementation while failing to focus you on building the foundation. The pressure was too much and I have relented to numerous requests on making that comparison. The caveat is that juxtaposing these models is not comparing different varieties of oranges or even apples and oranges; we are surely comparing the peel to the fruit they contain. Hence, comparing methodologies like Kotter's model (the peel), Prosci's ADKAR (the core), and General Electric's Change Acceleration Process (the whole fruit) need a different approach.

It was such an innocuous question, "Working on an article; what is the biggest problem you see with project governance at orgs? Can you comment?" Can I comment? Really? That is like cheese to a mouse. Where could I start—bureaucracy, draconian process, poor executive sponsorship, disengaged leaders? Plenty of fodder, because they all lead to project failure. I fired off, "Creating an over bureaucratic morass stifling innovation & implementing process instead of cultivating leaders." Then the maelstrom started and it went directly to the gap between the executives and projects managers. Naomi Caietti, Robert Kelly and I had a great conversation. Most of the thread is below.