image 

Stokely home 
Search 
Sitemap 
About Stokely 

The Lighter Side of Sysadm | Ranting & Raving | Pete's Back Yard

_____________________

Breadth of Vision - A Key to Successful Consulting

by Celeste Stokely, Copyright ©2001, Stokely Consulting

A successful move from full-time employment to consulting requires many skills beyond straight technical knowledge. One of the most important skills to develop is a "Broad Vision" in your client engagements. Being able to see much further than the immediate technical problem results in lots of repeat business, referrals from all over the place, and an "in" to more interesting and better-paying work.

I'm going to give you some war stories from my years as a consultant, and show you how the scope of vision I had at the time affected the outcome.


Fixing the Box:
A new customer needed a Sun installed and didn't know how to do it. He found out that I knew how, and asked if I'd do it for him. I installed it and there were no problems. Everyone smiled. They mailed me a small, but welcome check.

This type of straight technical work with no problems, as we shall see, rarely happens by itself. Still, it's an important component of all projects. You must never lose your technical "edge" and must keep your technical skills current or your consulting engagements will be overly frustrating and you'll become technically obsolete.

Don't confuse "Fixing the box" with consulting. "Fixing the box" is contracting. True consulting has many more dimensions, and requires the ability to bring a broader vision into play.


Fixing the Problem:
A client needed Solaris installed on a loaner machine. I started the installation and ran into a problem with a dead disk drive. I contacted the vendor and convinced them that, even though the vendor didn't want to deal with disk replacement on a loaner machine, it was in the vendor's best interests to send my client a new disk. I explained this to client, and explained that the whole project would be delayed while we're waiting for the disk to arrive. The disk arrived and I completed the task. Everyone smiled. The client mailed me a modest check.

The difference in this project is that I was able to work with a cranky vendor to get what the client needed, and able to set the client's expectations such that the client knew the project would be delayed, but still had faith in my ability to get the job done.

This situation comes up often. All consultants should have at least this level of proficiency in "managing the client, the vendor, and the situation". Some contractors would have just told the client "The disk is dead. Call me when you get a new one", and, quite possibly, not have heard back from the client.


Fixing the Real Problem:
A client wanted her company to use PPP on a Sun for Internet access from all the company's desktop machines. She asked me to configure PPP for her. I realized that before they can have their full Internet access, they need to reconfigure their internal routers more cleanly or no packets would arrive on the desktops. I explained this to client, got the go-ahead fix the router configuration, then configured PPP. Nobody was taking care of browser software, so I got approval to install licensed Web browsers on all the desktops. Everyone cheered. They mailed me a fairly substantial check.

I saw that fixing the original technical problem (configuring PPP) was not going to solve the client's overall problem of "Internet to the desktop". I was able to explain this to the client and get the approval to work on the "behind-the-scenes" problem (the router configuration) and approval to purchase and install good Web browsers. Taking the "broader view" on the project gave the client more confidence in my ability to solve her total problem, and let me design a solution that made the client far happier in the long run.

There are many consulting engagements that require this level of "tactical vision", even if neither you nor the client realize it at the outset. This level of vision and proficiency will get you lots of work at middle-tier rates. It will also bring in some referral work, though not as much as you may want.

This is where many new consultants' scope of vision stops: at the technical level just beyond their noses. But, it's not where the opportunity stops.

Now, let's move on to where the work is more involved, and the rates are more rewarding. But first, a word of caution.

"Solving the whole problem" is valuable if, and only if, that's what the client really wants. Otherwise, it's cowboy-ism that can lead to disastrous engagements. Never, ever, change the scope of an engagement without the full understanding and approval of your client.


Fixing the Department:
A client called me in to solve a problem in which the Unix users were hogging the Novell printers--she wanted to deny access to the printers for Unix users. I realized that this simple technical problem was masking a larger managerial problem--the computing resources were so few and laid out so poorly that everyone was fighting over them.

I worked with her MIS group to define a new architecture for the computing environment, giving different workgroups the types of fileservers and printers they needed to be effective. I helped them implement the solutions, and helped train the staff in the maintenance of the new systems.

The company began the long road to a better computing environment, the MIS staff was happier, and the users loved the improved access to the printers. This client has now been with me a long time, because I work with them to make everything run more smoothly for the company as a whole. A dinner was held to mark the successful completion of a long and involved project. They mailed me a very nice check.

Mastering this level of vision is the first step on the path to making serious money in fascinating realms of consulting. This stage separates the contractors from the true consultants and is the beginning of what most clients hunger for in their consultants--a broader strategic view of the customer's business and the ability to develop ways that the customer's business can be conducted more easily, saving the customer money in the long run.

If you have mastered this range of vision and chosen your market well, the phone will begin to seriously ring with referral and repeat business.


Fixing the Business:
It was the dead of winter. Demo time was coming for an ISP and it was for all the marbles. The president of a fledgling network service provider company in the mid-west called to say his engineers were fussing around with the production servers and now the servers crashed every hour. They were rushing to complete the working system to show to their investors, in the hopes of receiving another round of financing. A quick on-the-phone debug session with their engineers didn't show me the problem. He asked if I would please fly there, stay 2 weeks, and get them running. I didn't want to go live in snow for 2 weeks, so I quoted him an obscenely high daily rate, and, to my surprise, he agreed. So, the next morning I hopped on a plane. As soon as I arrived, I found that the servers' swap partitions overlapped the root partitions (they had not been entirely truthful over the phone when I asked about this) and they had trashed many configuration files. I fixed the errors, stabilized the servers, and the company was back on the air. But, was it?

It didn't take long for me to also realize that the engineers were developing new code directly on the production servers whenever they chose, installing new libraries with no coordination, not working to any plan or guiding principles, barely able to code in C in some cases, highly frustrated, and fighting over too few terminals to use.

I explained this all to the president, who was still so grateful over the servers being up that he listened to me closely. I told him that, while I'm no expert in release engineering, bug tracking, or configuration management, I had more experience in it than I saw there, and I was willing to help in any way to make engineering run more smoothly.

In 2 weeks, we got development machines set up, taught everyone how to use RCS, instituted daily bug-tracking meetings, bought books on C programming that became required reading, put someone in charge of testing and releasing new code onto the production servers. I also helped the president see that he was trying to build a world-class engineering organization out of talent he could find in a small mid-west farming community, and that's difficult. I helped him understand that if the company were somewhere that was more "engineering resource rich", like Silicon Valley, he'd have an easier time attracting professional developers and system administrators.

I stayed the 2 weeks. They shipped their product nearly on schedule, got their venture funding, went public, moved to Silicon Valley, tripled their staff, and landed several multi-million dollar accounts. This was some of the hardest work I've ever done, since it was a constant stretch of my capabilities. I burned up the phone wires talking with experts I knew in each field, staying a few chapters ahead of the client. I documented up my findings and the work we accomplished during that time, along with my recommendations for future action. It helped me grow enormously. They mailed me a truly gratifying check.

Without someone like me being there at that tender time, that company might not have gotten funded. I have received many excellent referrals from them in the years since.

It takes years of trial-and-error to develop this farther-reaching scope of vision, but it results in more satisfying work, work that is easier to obtain and pays in the upper tiers of the profession.

It will keep you from having to do what is easily the worst part of consulting--making cold calls to try to find work. When you behave as the professional's professional, you become something of a client magnet. They will find you.

Plus, when you have clients that value a professional's vision, they're often good professionals themselves, and far more pleasant to work with.


Celeste Stokely has been a Unix Systems Management and Project Management consultant since 1991. She is the author of Celeste's Tutorials on Modems and Terminals for Solaris and SunOS and the webmistress of www.stokely.com.


This article was originally published in the USENIX Association Newsletter, ;login, August 1996, Volume 21, Number 4.

_____________________

Stokely Consulting, http://www.stokely.com
Email: Celeste Stokely | Peter Stokely
163 14th Trail, Unit B, Cotopaxi CO 81223, (719) 942-3621
Copyright © 2013 Stokely Consulting. All rights reserved.