Providing Value to our Clients

A shepherd was herding his flock in a country pasture when suddenly a brand-new truck appeared out of a dust cloud on the farm road. The driver, a young man in an expensive suit and expensive hair cut leans out the window and asks the shepherd, "If I tell you exactly how many sheep you have in your flock, will you give me one?"

The shepherd looks at the man, obviously a city-slicker, then looks at his grazing flock and answers, "Sure. Why not?"

The city-slicker parks his truck, whips out his laptop, connects it to his 3G network, surfs to a NASA site, where he calls up a GPS satellite navigation system to get an exact fix on his location feeding the coordinates to another NASA satellite that scans the area in an high-def photo. The young man then opens the digital photo and exports it to an image processing facility in New York. Within seconds, he receives an email on his smart phone that the image has been processed and the data stored. He then accesses a SQL database with hundreds of complex formulas. He uploads all of this data via an email on his smart phone and, after a few minutes, receives a response. Finally, he prints out a full-color, 150-page report on his miniaturized LaserJet printer and finally turns to the shepherd and says,

"You have exactly 1586 sheep."

"That's right. Well, I guess you can take one of my sheep." says the shepherd. He watches the young man select one of his animals and looks on amused as the young man stuffs it into the cab of his truck.

The shepherd turns to the man and says "Hey, if I can tell you exactly what your business is, will you give me back my sheep?"

The young man thinks about it for a second and then says, "Okay, why not?"

"You're a consultant." says the shepherd.

"Wow! That's correct," says the city-slicker, "but how did you guess that?"

"No guessing required." answered the shepherd. "You showed up here even though nobody called you; you want to get paid for an answer I already knew; to a question I never asked; and you don't know anything about my business."

"…Now give me back my dog."


After reading this joke and realizing that there is a glimmer of truth in it, I started thinking about our business. Over the past few weeks we have put a lot of focus on the Statement Of Work (SOW) deliverables that we develop in the process of selling and starting new engagements. This is the first step in ensuring that we are providing the right solution to our clients and making sure that they understand what we are delivering to them. Sometimes we as consultants get mired in the minutae of projects and lose sight of what we were brought in to do as defined by these SOWs. We must all make sure that not only are we constructing quality solutions, but that those solutions MUST solve the correct problem. A $100 fire-forged, double gripped hammer may be the best hammer ever - but it has no use to someone who only deals with screws.

KISS with Duct Tape

If any of the readers of this have had the fortune (or curse) of working with me on any of my projects, you will already know this. But I am a HUGE proponent of KISS (Keep It Simple Stupid) methodology for designing Software (but can really be extrapolated to most areas of your life).

Early on in my career as a developer, I would strive to create "Art" in my code base. Trying to get the largest functionality, obscurity and "cool factor" from the absolute minimum number of lines. Often, this would require hours of rewriting, tweaking and research to squeeze out a few less characters in a statement. Once I was satisfied with my creation, I would sit back and glow in my own greatness - even if nobody else would ever notice or even care.

But then strange things started happening - any time something needed to be changed or heaven forbid there was an error in my code, nobody else seemed to know how to fix it. Team members would not understand the singular line of code that accomplished all 20 requirements for the function! Nobody else wanted to spend the time to research to figure out the obscure, deprecated function that was used. Slowly, the dim bulb over my head began to illuminate brighter. By creating the coolest thing ever, I had really inadvertently created more work for me. Hmmm... I began to reconsider all my efforts - did I really want to be the one always paged at 9 PM on Friday because the one line of code I produced was wrong and I was the only one who knew how to fix it. I did not.

At that point I began my journey back down the hill - back down to the perceived "common folk", which I now realize is really where I belong to begin with. After many years in consulting, one of the biggest tasks we have in creating solutions for our clients is to not only provide them with a application that works and performs all the necessary tasks, but to also provide them with something that they can understand and build upon themselves. Now, don't get me wrong, KISS does not give us the leeway to not do things correctly - just don't over complicate things needlessly.

I was recently reading a blog about a "Duct Tape Programmer" (read it) which really struck a cord with me. While I don't quite advocate slapping together a solution and calling it a day, there are many truths in this blog that we can all learn from. One of the biggest "features" of our projects is that it must be DELIVERED. Without delivery, it is all for naught.

Now, where did I put that tape?

How to Juggle Multiple Clients and Make them all Feel Special

We have all been there and if you are not there now, you will be at some point – juggling multiple clients (or maybe one client but multiple groups within the same client). How do you juggle all the work, keeping all the tasks on schedule and make each and every one of your clients believing that they are your primary client?


Organization is the real key. We all know techniques for keeping organized, so I won’t really discuss that. But once you are organized, here are a few things that may help you provide that white glove treatment all people really crave.

• Constantly prioritize your projects and their tasks. This may mean handling the highest profile project first, not necessarily the most urgent task.
• Ensure that you have committed enough time to complete your tasks.
• Learn to delegate and work as a team
• Don’t sit in your cube and wait for results to come to you. Be proactive and touch base with your projects every day or two. Don’t let them run on cruise control.
• Document important information about the client and make it readily available in a summary form - information such as names, roles, important dates and events (both project dates as well as important client dates such as vacations, graduations, weddings etc).
• Before your next scheduled meeting, quickly review the information – if an important date is near (either past or future) try to ask about that event

The hardest clients to juggle are those that you do not hear from on a regular basis – maybe weeks or months pass between communications. When they do contact you, they desperately need your help on a task that could consume all your time. Do you push your other client to the side and make room and hope to make up for it later? Or do you tell the client you are unavailable and you can either help them at a later date?

The first thing to do is to take a moment and assess the situation. How much of your valuable time would you really be able to provide without compromising your current clients. If the answer is none (or close to none) you should really tell them you are not available. If the client indicates that they really, really need you – do not cave in. Explain to them that you have other commitments – even as they complain, they will recognize your loyalty to your other clients and that you would be loyal to them and not bail on them either. It is all about setting the appropriate expectations.

Transitioning Yourself out of an Ongoing Project

We have all been on projects where team members have transitioned in and out during the life of the project, ramping up for a critical development cycle and then subsequently trimming down once that is complete. We all know the basics about what needs to be done when one of the developers or testers are rolling off the project. But what do you do when it is the Project Manager or Project Lead that is to roll off?

During the life of my current (soon to be former) project, I have had the role of Architect and Project Manager for a large application modernization effort - the client has a very large, home-grown application that is the core of their business. Unfortunately, it is hosted on a platform and technology that has been deemed no longer a viable solution due to upgrade paths and licensing fees. For the first two years my team has implemented the core architecture and development pattern for the client to move the entire application into a true N-Tiered, Microsoft .NET, SQL Server environment.

In addition to developing the architecture and teaching the client the correct way to do software, I was also involved in helping the client find talented developers and architects to be our corporate counterparts. These counterparts have now demonstrated to their management they have enough prowess and business knowledge that my role is now deemed obsolute as an architect - one of the downsides of doing our jobs too well, training our replacements so well that they actually do replace us.

So what are you supposed to do when you, the Lead or Manager is the one being rolled off? In this case, the project team is becoming even more of a staff augmentation delivery arm of the client - with the client performing all the architectural decisions and management. You, as project manager, have different responsibilities to the client as well as your team - which sometimes conflict.

For your client

• Determine the rigor that the ongoing project reporting and tracking should take on now that the management control is transitioned. Do we do status reports the same way? Who is on the distribution list?


• Determine the client personnel who will be taking on your tasks? Do they know what all the tasks are that you perform on a day to day or week to week basis?


• Determine how the client should communicate to your team and resolve issues.

For your team

• Determine the chain of command. Who does your team report to? Who assigns tasks and resolves issues?


• Determine how issues get raised back to your management team when necessary.


• Should your team still supply some sort of project reporting back to managemet? If so, what is the rigor and method?

There are a lot of other house keeping tasks that should be taken care of - almost as if the project is just getting kicked off - determining all the logistics of the project administration and day to day dealings now that the point of contact is no longer involved.

Guiding Decisions in the Direction you Wish

During my years in being an IT consultant, I have developed somewhat of an art to guide clients (and sometimes team members) come to the conclusions that I would like them to have, but in a way where they think that it either sprang from their own head or that we developed the idea together, as a team.

Some portions of this art has developed from my readings of Dale Carnegie's book "How to Win Friends & Influence People".

One of the short lists that come from this book is this:

12 ways to win people to your way of thinking

• The only way to get the best of an argument is to avoid it.


• Show respect for the other person’s opinions. Never say, “You’re wrong.”


• If you are wrong, admit it quickly and emphatically.


• Begin in a friendly way.


• Get the other person saying “yes, yes” immediately.


• Let the other person do a great deal of the talking.


• Let the other person feel that the idea is his or hers.


• Try honestly to see things from the other person’s point of view.


• Be sympathetic with the other person’s ideas and desires.


• Appeal to the nobler motives.


• Dramatize your ideas.


• Throw down a challenge.

The one of these that I have utilized the most and with greatest success is the idea of "Let the other person feel that the idea is his or hers." While this is not overly difficult to accomplish, it does take a little bit of preparation from your part. Not only do you need to know what conclusion you wish to have, but you also must think about logic steps that you can use to lead the other person to this conclusion.

In order to lead the other person, you can use a couple of the other items in the list to help: "Try honestly to see things from the other person's point of view" and "Let the other person do a great deal of the talking." By using the point of view idea in your preparation of the discussion, you will hopefully be able to identify the question or concerns that the other person may derive during your discussion. Knowing where they may have issues, will help you either guide around the issues or enable you to alleviate the issue. By allowing the other other person to do most of the talking, but interjecting your own ideas to help guide the conversation, you allow the other person to connect the dots logically, working out a solution for themselves.

A key aspect to all of this is that you must let go of the fact that once you have guided the other party to the conclusion, that it will no longer ever be considered your idea. This is sometimes hard for people to do - give up credit for a really great idea. But in the consultant world, the final result, and the clients feelings about the entire engagement, is much more important than who gets credit for the idea.

The Art of Managing Young “Rock Stars”

One misconception among IT managers is that they should be better at everything than everyone working for them. Nonsense—it’s the manager’s job to determine the team’s strengths and weaknesses and create a strong team, not to do it all the work yourself.

Now picture this: Some 23-year-old developer fresh from Microsoft U. is telling you how the basic applications you helped architect two years ago, the one that you’ve been able to scale and maintain through the past 24 months—well, that solution is pretty stupid, according to your junior report.I’d like to say most managers understand that you can’t just snap back and tell your inexperienced team member to shut up, even with nice words. Getting defensive about your own accomplishments, goals, and motives is a natural human instinct that you’ve got to contain as you initially respond to such criticisms. But checking your ego doesn’t stop at just refusing to get into an argument with some smart-aleck kid.Because the kid may be right.

Recognizing, and even rewarding, employees who have better ideas than your own while maintaining your position as the team’s leader is absolutely one of the toughest challenges in management, especially in an industry where bright young talents are often referred to as “young guns” or “rock stars.” You want to hold on to these rising stars, and take advantage of their good ideas and passion to demonstrate how smart they are. Those are their strengths. Rock stars can drive you and other team members crazy with their rash comments, careless bravado, and resistance to constructive criticism. Those are their weaknesses. Drawing a map that makes these two routes converge at success can be a nightmare.Here are a few tricks that have helped to contain young employees’ ego without undermining leadership positions.

· Remember that you were once the kid that’s now staring across your desk at you.
Look back at past conflicts you had with your own bosses and use those experiences to build empathy with the frustrations that your junior team member is probably feeling.

· Let your young employee try out a bad idea and fail—or maybe succeed. Nothing teaches like experience, particularly in the case of headstrong young talent. Consider developing a controlled environment in which he or she they can try out the idea. The kid may be right, after all.

· Make the employee explain what went wrong, and how we can do it better next time.. Don’t be mean, but don’t be overly gentle of mistakes, either. Allowing a team member to try something new for a time is a gesture of respect on your part, and it entitles you to be candid in evaluating the results.

· Go out of your way to give credit where credit is due. If a team member’s idea pays off, make sure everybody knows that it was that team member’s idea. Nothing erodes the basic trust between a manager and an employee than the notion that the boss is taking all the credit for the employees’ contributions.

· Don’t be afraid to draw the line. Just because you are willing to entertain challenges does not mean that standards will not be enforced. Revert to “management” mode to establish a line between “practices” and “business values.” Clearly laying out the ground rules will give the employee the parameters for constructively challenging your ideas and you won’t find yourself backed into the “Because I said so” argument.

Get used to it - it never stops
No matter how long you have been a leader, dealing with criticism from your team will always be a challenge. Even as you gain more confidence in you decisions there will be an unlimited supply of up-and-coming stars that will challenge the process. But remember, as those kids learn from the mistakes you let them make, you will be able to place them in project leadership sooner than later. And one final silver lining (and sweet, sweet irony) – they may even become the managers that have to deal with the next generation of “rock stars” themselves.

Boiling the IT Frog

Here is an excerpt from the book “Boiling the IT Frog” by Harwell Thrasher.

“IT people are very focused on the how, not on the what. The most common mistakes they’ll make are errors caused by doing the wrong things, not by doing things wrong.

Tell IT people what you want to do and you can almost see the gears turning in their heads as they evaluate alternative approaches and eventually come up with various options on how to accomplish your goals. IT people are so focused on the how, in fact, that the most common mistakes they’ll make are errors caused by doing the wrong things, not by doing things wrong. That’s why an IT strategy is so important to a business; it’s the only way to be sure that your IT organization is headed in the right direction.

Some of the worst difficulties in communicating with an IT organization are caused by differing definitions of nontechnical words. For example, IT people frequently use the word project to mean the software development part of a larger Project that includes everything necessary for the business deliverable: design, building, testing, documentation, training, implementation and infrastructure additions. Thus the completion date for a project may be viewed by IT as the completion of the software work. If you don’t clarify the deliverable, then there will be a huge misunderstanding.

Similarly, an IT organization might commit to have some work done by the third quarter. The IT customer will assume this means July 1, but the IT organization will assume it means Sept. 30 at midnight. “

Some other aspects to the book refer to the idea of boiling a frog: meaning, if you place a frog in a pot of boiling water he will jump out immediately. But, if you place a frog into a pot of cool water and gradually heat the water to boiling, the frog will not recognize that the water is hot and will eventually be cooked. This is a good paradigm that we, as IT groups, should be aware of. Sometimes we get so involved in the depths of our project work (developing, debugging, data conversion etc) that we do not recognize that the project as a whole is in serious trouble – we fail to recognize the world around us and perhaps the pressure points have changed. We all should get in the practice of periodically taking a step back (or out) from our daily tasks and routines and truly analyze our projects.

· Has the client’s perception changed?

· Has the client’s business direction changed? From a strategic standpoint, is this project still in line with where they are headed?

· Has the project evolved into something other than what we originally planned? This is usually a good thing, but we should reevaluate to see if it is still heading in the right direction.

· What else is happening in your client’s organization? Are there any new efforts popping up that are in competition with your project? Or maybe an effort has started where we can identity new integration points to expand your project.

The point is, if you don’t stop and take time to evaluate your surroundings from time to time, you (and your project and project team) may end up in boiling water.

Keep Your Team On Track with Standups

Are you having a hard time keeping your team members focused and on track? Or maybe you have a team member who gets lost in the weeds for extended periods of time. Or maybe your team does not communicate enough with one another. One technique that I have borrowed from the Agile world is the use of the Standup Meeting.
The standup meeting is a very useful tool to help you – the project lead – keep team members on task as well as get the team in the habit of keeping each other in the loop without spending hours every week in endless, agonizing status meetings.

Standup meetings provide a simple means for team members to keep each other up to date without spending a lot of time in meetings or having to write and read piles of status reports. They focus on quick discussion of progress, plans and problems. This allows team members to get timely updates about others’ progress while you – the project lead (or manager) – quickly determines their tasks for the day by virtue of the team’s obstacles.

There are two key aspects to the Standup Meeting that will make it a powerful tool. The first is in the name of itself – “standup”. Standing encourages concise discussion of progress, plans and problems. When sitting, people get too comfortable and will expand unnecessarily on some points of the update. Standing promotes the feeling of urgency – of a quick hallway conversation and the team will focus on the really critical bits. This is important because if the meetings are short, concise and informative, the team will see value in them and not try to avoid the meeting. A general guideline is to keep the meeting limited to 10 or 15 minutes.

The second key aspect is a little more subtle and will start the team down the path of richer collaboration: encouraging team members to provide updates to each other, not just to the project manager. By doing this, the team starts to see the Standup Meeting as a tool for coordinating their work and keeping up to speed with what others are doing, rather than a necessary evil endured only to silence the constant "are you done yet?" questions.