Is there a place for creativity in IT

The answer to the question posed in the title is yes, and the more creative you are, the better your career will be. Actually, that holds true in just about any field, except perhaps finance. (In that case, you may richer due to creativity but, if there’s a God, you may also be handcuffed one day and taken to the big house.)
But back to IT. Most people outside of IT probably have a certain image of a computer engineer — a very analytical, A equals A type of person. More than likely Bill Gates comes to mind. And Mr. Gates is inarguably successful.
But then you have success as defined by someone like Steve Jobs, whose death struck such a chord among the general public. He combined technical genius with creativity — he dreamed what could be and made it happen. Gates changed all our lives by making extraordinary tools and showing us how to use them. Jobs changed our lives by turning our dreams into tools.
But those are the big guys. Does creativity play a part in other aspects of IT? I wondered to myself if a developer, for example, would consider himself or herself creative.
I asked Jeremy Lwanga, a Senior Web Developer at CBSi, if he thought creativity played a role in his job. He said that was an interesting point of view. But then when he thought about it, he said that yes, “a good coder has to think of new ways to use old code” and that he strongly agrees that it plays a big part in one’s IT career success.
So there is the analytical side of having a set of tools (the .NET framework, for example), but then there is the figuring out how to put the pieces together in new and interesting ways. It’s like they all have the same “palette,” but each coder has the opportunity to use the “colors” in a different way. If you have the talent to recognize and implement this, then you are going to be more successful.

When to apply the shut up strategy

Takeaway: Before offering clients your unsolicited opinions, you should consider whether holding your tongue might be necessary in order to maintain a good client relationship.

Clients pay us for our input — that’s why we call ourselves consultants. But that doesn’t mean clients want our opinions about everything. Knowing when to speak and when to keep silent distinguishes the art of consulting from its imitations.

Obviously, if your client asks for your opinion on any subject, you should provide a response. But don’t be afraid to admit your ignorance and offer to research it, rather than fabricating something on the spot.

When you consider offering your unsolicited opinion, ask yourself whether this topic could impact the outcome of the project for which they hired you. If so, then you must speak up, no matter what other objections you face. Otherwise, you’re neglecting your duty to your client.

Even if not directly related to your project, if you perceive a potential advantage for your client to embrace, or a disadvantage for them to avoid, then you should bring it to their attention. The more the subject falls into your realm of expertise (or out of your client’s), the more this rule applies.

Consider whether your client has already made up their mind on the subject. Unless you can demonstrate a clear risk or opportunity, you have no need to beat that dead horse just to voice your personal preferences.

Don’t discount emotional ties to a prior decision. Humans naturally favor their past course of action (choice-supportive bias). They may possess other non-logic-based ties to a particular path, too. These might include feeling aligned with a group, especially the “in crowd.” You can spot that by their use of the word “everybody,” or its equivalents like “enterprise developers these days.” Questioning their decision threatens to separate them from the right-thinking group. The need to stay with the herd runs deep.

Given these considerations, we can easily see that topics such as religion, politics, and sports fail nearly every test. I avoid having these conversations with clients unless I know them well enough to feel certain that we can conduct a friendly, non-threatening discussion that won’t strain our relationship. In fact, when you can do that, such dialogues strengthen the bond between you and your client. But if you try to open those subjects too early, they’ll likely label you an opinionated jerk.

It gets much more tricky at the edge cases, however. Something like your client’s choice of development frameworks can border on religion, yet it can also pack a heavy punch for your project. You need to balance each of the considerations above, and if you decide you should speak up about it, be careful how you approach it. “I can’t believe you’re using X! Man, you should be on Y!” is equivalent to saying “Whoever decided on X is obviously a biased idiot, or at best negligent in considering your options.” That directly threatens the status of said person. It also paints you in bold Y-fanboy colors. Instead, try something less emotional such as, “I think you could benefit from revisiting that decision.”

Sometimes, we just need to realize that we live in a sub-optimal world. Constantly revising decisions in order to always make the best choice will result in never getting anything finished. Sometimes you just need to run with what you’re given. After all, it’s not the system, it’s the execution that matters. Other times, taking a step back and changing directions can make all the difference. Knowing which is which is part wisdom, part luck.

What to do when you get in over your head

Takeaway: You don’t have a clue about what you’re doing on an IT consulting job. Here’s advice on what to say when you come clean to the client.

It hasn’t happened to me for a long time, but back when I first started consulting independently I would sometimes find myself in a situation where I really didn’t have a clue about what I was doing. Maybe it was the need for income or an overinflated opinion of my own abilities that led me to take on a project in unfamiliar territory — but whatever the reason I would suddenly wake up to the “uh oh” of the situation. I’d feel like a hole was growing beneath my feet, imagining how my client would react if they knew that they had hired a consultant — a supposed “expert” — who knew little or nothing more about what to do than they did. Naturally, the next thought to come to mind was “what now?”

Should you cram for it? Google it like mad? Ask all your colleagues about it? Buy a book? Work extra hours on it on your own dime to get familiar with it?

In my experience, the first thing you should do is come clean to your client. If you try to hide your ignorance, it’s likely to show through anyway — and you’ll have to spend way too much time weaving lies. So, how do you tell them?

Hello, Client. Look, after getting a little way into this project, I found that it requires knowledge of some things that lie beyond my experience. That’s likely to add to the time required to complete the project, as I’ll have to research those areas first. I’m sorry I didn’t spot that when we first contracted for the work. I’d be happy to continue if you’re willing to fund and wait for the research, but I’d certainly understand if you need to give the work to someone else more familiar with the problem domain.

You might even give them a break on your rate for contributing to your education.

Owning up to the problem usually elicits a “thank you” from your client, regardless of what happens next. If they consider you for subsequent projects, they’re likely to ask you “Are you sure you understand this fully?” But at least they’ll know that they can believe your response.

Naturally, the best thing is to avoid getting into this situation in the first place. Know your abilities, as well as your deficiencies. If a client wants to engage you for something about which you know little, tell them so. Offer to research it, or to refer them to someone who is more familiar with the subject. Don’t be afraid to lose the work because you don’t know the ropes. In that case, you probably don’t want the job anyway, and you surely don’t want to try to pass yourself off as an expert.

Unrealistic project estimates: The IT consultant as an enabler

Takeaway: All IT consultants have given clients unrealistic estimates at one time or another. Get tips on how to resist the pressure to give ad hoc estimates.

Here’s an all too familiar scenario:

Bob the client calls and says, “We need to add this small feature to our application. How long will it take?” You respond that you need to draw up some requirements and talk to users, but Bob counters, “Oh, just gimme a ballpark estimate.”

The gears start turning in your brain as you imagine implementing the feature as described. Your natural optimism thinks you could complete the work in three days, but you know you can be overly optimistic, so you answer, “Two weeks.”

Guess what? You’re still short. You forgot these important factors:

• Requirements. Your client contact, whether they’re the CEO, CIO, project manager, or whomever, cannot have a complete picture unless she or he is the only user — and even then it’s dicey. Besides, there’s no guarantee that what you took from their brief description even matches what they meant.
• Design. You don’t want to jump in and start cowboy coding without a proper design of each component. I’m not talking about flowcharting everything or generating piles of UML that nobody will ever read again; your design needs to be flexible but well thought out. Even though this seems like it adds time to the project, failing to do this step adds even more time in the long run.
• Testing. I’m a big believer in writing your tests before you write the code to satisfy them — or at least, in parallel. This is another step that saves you time down the road.
• Iterations. No matter how well you define the requirements up-front, somebody will forget something important or something nobody even knew. You need to build in time for providing prototype versions so the client can use the product and provide feedback that drives new requirements.
• Documentation. A system that isn’t documented will be reinvented. If you want the project to have any shelf life, you need to provide usage instructions for people you may never meet and put enough comments in the code that you’d be able to understand it even if you hadn’t written it.
• Training. No matter how well you write, users may not be able to grok what’s going on without some personal guidance.

Taking shortcuts that cost more time in the long run

Consultants often leave out some or all of the above steps in an attempt to provide results quickly. Bob may be impressed when he gets the new feature in less than a week, but pretty soon, he’ll find out that the project isn’t quite done yet. In fact, you’ve only completed the first iteration, and even that was half-baked. The project will probably drag on for months or even years, as you tweak the features, fix the bugs, and give the users the same instructions over and over again.

So, why do consultants take shortcuts that make the journey longer? Here are four reasons:

• Client pressure. Bob wants you to give him a low number, so he can justify the work. You don’t want to disappoint Bob, and you want him to approve the project.
• Competition. If you aren’t the only bidder on the project, you want to be the lowest bidder so you get the gig.
• Hubris. No matter how much you pad an ad hoc estimate, it still isn’t worth the air that it’s written on. But once you’ve stated a number, your pride and your standing with the client won’t let you admit that you were wrong. So you cut corners.
• Pure evil. Some consultants get the client on the hook by intentionally engineering the project to require follow-up work after it’s “done.” Those consultants give the rest of us a bad name. (They should really read my column, “An independent consultant’s code of ethics.”)

Fending off pressures to give ad hoc estimates

I have three recommendations for how to resist these pressures:

First, consultants have to be aware that these pressures exist. When I was a newbie consultant, I had no idea why projects always took longer than expected — my estimate always seemed reasonable to me at the beginning. Learn from past projects — what went well and what didn’t, both in your experience and in the experiences of others.

Second, consultants have to educate clients on what a well-executed project requires. Clients need to understand that by taking a month instead of a week, they’ll get a finished product that meets their needs instead of one that does exactly what they said but not what they meant. And even if it does require modifications after delivery, they’ll be easier to implement without breaking something else.

Third, consultants should not give ad hoc estimates. If your client won’t stop bugging you until they get one, then say, “sometime between a month and 10 years” because frankly, that’s about as precise as you can be without more information. Instead, you should push for approval of an exploratory project to establish requirements and compute a decent estimate.

Building a reliable reputation

Unfortunately, because so many self-styled consultants are willing to cut corners, they’ve set the expectations in clients’ minds about what estimates mean. The more intelligent clients have come to expect that the project estimate will be far less than what’s really required when all is said and done. So when they receive a more accurate estimate, they’re likely to think that the actual timeframe for having something usable will be much longer. You need to build a track record of reliability before your client can trust your prognostications.

Talking Shop: Improve your communication skills with these techniques

Why didn't you get the last promotion or new job for which you applied? It could be that the person who got the job knows more about technology than you do. Or maybe it's because poor communications skills let you down.

To those who couldn't care less about their communication skills, I say "good luck," because you'll get what you deserve in your IT careers. For those of you enlightened enough to realize that your communications skills are just as important as your technical abilities, I'd like to offer a few tips for improving the way you communicate on the phone and in person.

Pet peeves about poor phone etiquette
Whether you work the help desk, the network operations center, or as a developer who rarely interacts with end users, here are three ways you can build a reputation as a good communicator by practicing phone etiquette.

• Use a warm transfer instead of a cold transfer. If a customer (or fellow employee) reaches you by mistake, don't just say, "You have the wrong number," and hang up as quickly as you can. Don't say, "Just a minute" and transfer the call to someone else without explanation. That's a cold transfer. Take a minute to pull up your company's phone directory and try to figure out whom the person really needs to reach. Then, say, "I'll be happy to transfer your call," and announce the call to the person on the receiving end. That's a warm transfer.
• Say your name when you answer the phone. Don't be the arrogant jerk who answers a business phone, "Hello." Not every caller is going to be your spouse or a coworker who recognizes your voice. Sometimes it's a person with a problem, and they've been referred to you. If you don't say your name, the poor caller has to say, "Is this so-and-so?"
• Answer your voice mails in a timely manner. I don't know how many times I've heard end users or customers complain about how so-and-so in information systems is never at his or her desk and never returns his or her calls. You want to establish a reputation as a good communicator, so respond to your voice messages. Don't be the arrogant jerk who assumes that, "If it's important, they'll call back."

Improving your face-to-face communications
You've heard the old saying, "It's not what you know, but who you know," that gets you places in business. Guess what? If you don't practice good face-to-face communications skills, you're not going to get to know very many people.

• It won't kill you to smile. I know you're busy. I know providing tech support is stressful work. But when you walk into a conference room for a meeting, or when you walk up to an end user's workstation to provide support, for crying out loud, SMILE! Fake it, if you have to, but act like you're glad to be wherever you are. Don't go around with a scowl on your face all the time. If you're that unhappy, get out of IT and go find a job that you love.
• Look at me when I come to your cube. This is the biggest pet peeve I have about my fellow IT pros. I go to someone's cube to ask a question in person. I knock on the cube wall. I stand and wait, while the uncaring, rude, egotistical snob stares at the screen, not even acknowledging my presence. You know the ones. You clear your throat or say, "Pardon me, please," and the jerks don't even speak. They just nod, still looking at the screen, typing or clicking away. Hear me now and believe me immediately, my cyberfriends: There is nothing so important on your screen that you can't turn and face the person who has come to visit you. If for some unimaginable reason you really can't avert your eyes from the screen, have the courtesy to say, "I'm sorry but I'll be with you in just a minute."
• Invest in breath mints. My last pet peeve about face-to-face conversations concerns you five-break-a-day smokers and constant coffee drinkers. Buy a tin of Altoids, will you? Or buy a toothbrush and a tube of toothpaste just for the office, and use them. You're stinking up the place. (Read "Perfume allergy makes tech support painful" by TechRepublic contributor Becky Roberts for a take on dealing with user-related odor issues.)

You're in control of how you come across
For many of us, the perfect techie world is one in which we'd be hired and promoted on the basis of our technical skills alone. But we live in a world where we're judged by how we communicate with fellow human beings. Don't let sloppy telephone and in-person communication skills prevent you from succeeding in the "bitnit" world.

In a future column, I'll share some tips for improving the way you communicate in written communications. In the meantime, be nice on the phone, and smile once in a while. It'll be good for your career.

Prioritize consulting tasks by mapping them to client goals

Takeaway: If you’ve ever spent loads of time on a task that turned out to be unimportant to the project, then check out this five-step process for analyzing clients’ priorities.

If your consulting business is healthy, then you probably have more items on your to-do list than you can possibly accomplish. That’s the feast side of the feast or famine phenomenon, which doesn’t really need a name as impressive or as spooky as phenomenon — having a name for it at all is only a recognition that keeping the flow of new work in your pipeline at an optimal pace at all times is nearly impossible.

Let’s assume that you can already successfully allocate your time between multiple clients. An individual client may still ask you to do more for them than you can squeeze into their allotted hours. So, you have to prioritize the tasks you’re given.

Sometimes, your client will do that for you; if they have someone onboard who consistently organizes project priorities, consider yourself blessed (here’s looking at you, Rosanne). Most of the time, though, your client expects you to guide them — you are the consultant, after all. So you end up prioritizing not only your work, but also the tasks of other players within the client’s organization.

Here are five steps you can take to insure that you do the most important things first.

1. Name each of the results you’re asked to produce. Write down the results in a list.

2. Identify the goals that each result would meet. For each goal, ask yourself: Why do we want to do this, and what does the goal accomplish? Then consider whether there are any goals that aren’t addressed by your list of results from step 1. If so, you may need to go back and expand that list after bringing it to your client’s attention. And if there items that don’t meet important goals, perhaps you can eliminate those items.

3. Identify interdependencies between these results. If you can’t achieve result B without first achieving result A, then the priority of A must be higher than the priority of B. You can represent that by including the goals achieved by B within the list of reasons why you need A.

4. List and prioritize all of the goals from step 2. You should seek your client’s input on all of these steps, but especially this one. It’s possible that your client may not have a good handle on what’s more important to him, but at least now you can frame the question in terms of goals rather than tasks. Help him by asking questions, such as “How painful would it be to miss this goal?”

5. Order results according to goals and dependencies. List each of the results in step 1 according to the priority of goals from step 4. Make sure that prerequisites identified in step 3 are listed ahead of the tasks that each prerequisite enables.

By mapping tasks to goals, you’ve created a to-do list in priority order. The items near the top must be accomplished first; the items near the bottom can wait; and some of the items may even be optional. None of this will work unless you can answer all of the questions in each step correctly — that can only proceed from good conversations with your client about what’s important to him, followed by thorough research on what you’ll need to do to accomplish his goals.

These steps will work for employees who need to prioritize their work, although they’re particularly useful for consultants who regularly get work thrown at us by clients with the expectation that we’ll just handle it. If we don’t take time to prioritize our tasks, we can come up short on our clients’ expectations. Clients might wonder why we would be so stupid as to put all of our attention on a relatively unimportant task first, even if they were actually at fault for not communicating their priorities to us in the first place. We can proactively insure that doesn’t happen, though, by analyzing clients’ priorities in terms of their goals.

Laying the groundwork for a successful pitch to clients

What’s the best way to convince a potential client to sign on with your consultancy? Obviously, it’s to convince them that you can do the job in the best possible way and that you can get great results with maximum efficiency.

Unfortunately, most companies try to interview contractors the same way they do potential employees. You probably already know that enduring hours of interviews by an endless procession of managers and teammates is not the best way to sell clients on your services.

Instead, you need to give a convincing presentation for all the key players. In this presentation, you present yourself as a dynamic and capable person who will not stop until this project is a success. It’s much easier to convince people of this in a presentation than in a string of one-on-one interviews that waste your time and drive you to recite your points in an emotionless monologue.

In this article, I’ll share with you how to lay the groundwork for an impressive presentation.

---

First of two parts
This week’s article gives tips on the prep work you'll need to do before giving a presentation to a potential client. The next installment will show you what to include in your presentation.

---

Gather all the key players
The most important key to the success of your business presentation is to have all the right people in the audience. Putting on the same presentation again and again is little better than dealing with monotonous interviews because it starts to sound forced and rehearsed. Besides, making 10 one-hour pitches to 10 different people is money down the drain for a contractor.

Instead, make it your first priority in your contact with a potential client to schedule your business presentation with all the key people. I approach this by asking my main contact for the names of every decision maker involved with this project. I then ask when is the first available time that we can schedule a presentation with all of these people in attendance.

If my contact says that it will be difficult to arrange a meeting with that many people, I point out that all of them need to attend because otherwise, I’m wasting both my time and the client's time.

You may be thinking that this is easier said than done—we’re all familiar with client chaos during the hiring phase. But it’s a red flag if a potential client is unable to get the key people in the same room at the same time, and you should seriously reconsider whether you want to work with such a client.

If you’re having trouble making this happen, express your concern to the appropriate person at the company. Politely let that person know that you can’t make his or her project a success if he or she can’t gather the decision makers into one room for one meeting.

At worst, clients will ignore their own problems and write you off as arrogant, in which case you were doomed for failure there anyway. But if the clients are committed to the project’s success, they should schedule the meeting, figuring that a can-do person—such as yourself—is just what they need.

Be prepared
Once the meeting is set up, get ready. Do as much research as possible on the company and, if necessary, on the skills you’ll need for the project at hand. Be prepared to field any questions. (For research tools, check out my earlier article, “Research your clients before agreeing to work with them.”) Can you offer any insight into what the competition is doing? Can you demonstrate familiarity with a tough market issue that the client is facing? Can you provide an anecdote of how you helped another client out of a bind similar to what the client is going through?

Know the turf
Next, get familiar with the place where you’ll be making your presentation. Your goal is to feel comfortable and be prepared. If it’s at the client’s offices, schedule a time to drop by at least a day or two before the presentation. You want to make sure you know what to expect and whether the necessary props are at hand there, such as a whiteboard or a projection screen. Try to make sure the room will be available at least 15 minutes before you’re supposed to start; you don’t want to be fumbling with equipment while everyone looks at you.

Geeks and communication skills

Takeaway: It is a commonly held belief that geeks do not need to be able to communicate outside of Nerdland. In fact, it is an outright expectation. Programmers who gets nervous around pretty girls, systems administrators who cannot give a presentation to more than two people at a time, and DBAs that stutter unless they are [...]

It is a commonly held belief that geeks do not need to be able to communicate outside of Nerdland. In fact, it is an outright expectation. Programmers who gets nervous around pretty girls, systems administrators who cannot give a presentation to more than two people at a time, and DBAs that stutter unless they are discussing Dungeons and Dragons are what many people envision when they think of IT professionals. These are all common stereotypes of IT professionals. Sad to say, many IT professionals buy into this idea, and sometimes even actively encourage it!

I am not going to pretend to be surprised by this. Up until the age of sixteen or so, reaching Level 4 as a bard seemed more important than reaching first base with a woman. Weird Al Yankovich was “romantic” in my mind and a “nice wardrobe” meant a closet full of shirts from hardware and software vendors, preferable ones with multiple years’ worth of pizza stains on them to prove my “authenticity”. I thought that if people did not understand me, it was because they were stupid, not that I was unable to communicate with them.

Thankfully, I changed. Mostly. I still think Weird Al is funny on occasion, and the ratty shirts are still there (though they now tend to be Metallica and Mr. Bungle shirts from my post-ubergeek years). The biggest change was that my communication skills improved significantly. I took classes in high school such as AFJROTC and Mock Trial that taught me how to speak to an audience, with or without notes. My classes in college (I will merely admit that I double majored in “cannot-get-a-job-ology” which is code for “the liberal arts”) involved few tests, but endless amounts of paper writing. What few tests there were tended to be essay questions. In other words, I was learning a lot about communication skills.

What does this have to do with the IT industry? Plenty. If you want to know why your manager seems to be a “grinning idiot” with no clue what your job is instead of someone with technical skills, take a look at what that manager brings to the table. That manager is very likely to have an MBA or maybe an MIS degree. Their external learning is probably in “risk management” or Six Sigma, not the Cisco or Red Hat certification you just earned. The manager’s job is to interface between “the suits” and the IT people. The manager does not actually need to know how to do your job if you communicate your needs to him properly. What manager does need to know is how your job relates to the business.

It has been my experience since I started blogging about IT issues on TechRepublic, that the majority of the time when I receive heavy criticism, it is because I failed to write clearly and properly communicate my message. Sure, there have been instances where someone climbed all over me for using one bad example or analogy in a 3,000 word post, or where someone was obviously unable to comprehend the topic at hand. But by and large, when I receive negative feedback, it is my own fault for not writing clearly.

At my current position, my manager does not understand much programming (he knows some VBA), systems administration, database administration, networking, computer repair, or any of the other tasks I do. He knows how to run the company, deal with customers, and so on. He really does not need to know the gritty details of what the project is hung up on; he just needs to know how long the delay will be. He does not care what brand of motherboard I buy or what CPU I select; he needs to know the price and business justification for the expenditure.

Many of the IT people that I have worked with simply do not understand this. They fill a proposal with technical details, and expect the person reading it to understand the benefit of the proposal from the technical information. In other cases, they write an email that is littered with typos and spelling mistakes. These types of mistakes do not help the recipient to understand why they should approve your request or give your project more resources, or otherwise help you with whatever goal it is that you are trying to accomplish. Tailor your message for the audience. If the recipient is a technical person, make it technical. If they are a non-technical person, use language that a non-technical person can understand. As I often do for programs that I have written, I pass it through the “Mom test.” In other words, I ask my mother to review it. She is about as non-technical as it gets. If my mother can understand what I have written to the point where she can make an educated business decision, then it is a good communication.

Many of the IT people out there seem to think that this is degrading. These are the same types of IT people who make web sites that only display in one particular web browser, or require you to go find some funky external library, or insist that you recompile the application yourself without providing any documentation. These are the IT people that may be excellent at their jobs, but are hated by everyone that their job touches. You do not need to go this route. No one will criticize you or complain if you learn to effectively communicate with non-technical people. In fact, they will appreciate you even more. My experience has been that improved communications skills leads to better opportunities in life and in my career. If a manager is evaluating two candidates for a promotion, they are more likely to pick someone with less technical skills who communicates well than a more technical person who does not communicate well. Why? Because the person with good communication skills is able to show that they know what they are talking about, while the person without those skills simply cannot be understood.

If you feel that your communication skills may be lacking, there are things that you can do to help them improve. One suggestion is to read more books and magazines. If you already ready books and magazines, escalate the difficulty level of your readings or try reading about topics that you are not familiar with. I have found that crossword puzzles are great tools to expand your vocabulary. Try your hand at writing something, whether it be short fiction, how-to articles, or poetry. If you can, try to go to new places or talk to different people; sometimes we find ourselves in cliques with a shared mindset that makes it difficult to learn how to communicate outside of that group. There are lots of different ways to improve communications skills, but at the end of the day, they all amount to “increase the frequency of your communications, the diversity of the mediums, and the people that you communicate with.”

Manage client expectations with a project scope document

The middle of delivering a service or project deliverable is too late to begin managing a client’s expectations. To be successful, you have to start managing expectations at the beginning of every client request. It would be nice to be able to take the quick and easy path of just discussing an issue or request with a client and then doing the work. The challenge is that people hear and interpret the same message in different ways. To protect your client and yourself, take the time to develop a detailed scope document on the front end of any project to manage both of your expectations.

What does a scope document achieve?
The essence of the scope document is always to state to your client, “This is what I heard you say, this is what I plan to do, and this is the cost of the effort.” Making this statement:

• · Forces you to think through the elements of the project or request.
• · Gives the client your interpretation.
• · Verifies the project’s who, what, when, where, and how.
• · Forces the client to validate your interpretation of the planned work.

The level of detail you put into a scope document will vary based on the project and your client. In some cases, I simply use a follow-up e-mail or short letter to clarify what I’m planning to do based on a conversation. But usually in my consulting role, it’s my standard practice to create some type of scope document before I do any work for a new or existing client.

Elements of a scope document
Here’s a brief look at what your project scope document should address.

The problem or need
Describe the problem or project request briefly. By doing this, you restate the issues as described by your client, helping confirm your interpretation. Define the project’s goals and objectives. This section doesn’t have to be lengthy, but you need to include enough detail to ensure the client’s needs and objectives are clearly outlined.

Deliverables
Describe all deliverables that will establish the successful completion of the project. If your work includes programming changes, include an application design or a summary of the software development effort that provides enough detail for the client to see and agree on the deliverable. For a Web site design, this might include a short written description as opposed to detailed Web page designs. Gauge the level of description you need based on your client’s need for detail and the complexity of the project.

The plan
Define the specifics of the work plan to a level of detail that helps the client understand what you plan to do in the project and how the process will work. Clarifying issues that will keep your client out of the dark makes it easier for your client to do business with you, reduces questions, and helps you achieve a positive experience with your client. The plan needs to include key milestones and estimated timeframes to the extent that you can define them.

Resource needs
Quantify the resources you’ll need from the client so he or she can plan for the effect your work will have on the organization.

Cost
Be as specific as you can with your cost estimates to prevent misunderstandings later. Consultants use many different cost models, such as billing time and material, giving a fixed project cost, and working on a monthly retainer fee. Clients have to justify your consulting expense and the better you can articulate your cost, what it’s for, and the deliverables the client will receive by spending the money, the more likely you are to be paid without issue. The bottom line is that there should not be any guesswork on the client’s part about how much a project will cost and what he or she gets for it.

Payment plan
Define when and how you should be paid for the project. Again, state this information up front to avoid creating confusion and building up an accounts receivable balance.

Project scope document
Use this sample as a guide to help you develop your next scope document.

Final thoughts
Creating a definitive scope document helps eliminate confusion with any project and presents you in a more professional light. Consultants that provide professionally delivered services often get called back or recommended to other companies.

Use the scope document as a means of managing your client’s expectations from the start. Too many client dissatisfaction issues occur because the client’s expectations aren’t managed up front. Start every project venture out on the right foot by stating the project’s scope clearly and you’ll reward yourself with fewer problems down the road. Once you get into the habit of developing a scope document at the beginning of new projects, it will become a quick process and one that saves you valuable time later.

How to develop and maintain client relationships

“One thing is true for all consultants: If we have any work, we have clients. And one of our most important roles is to maintain and enhance our relationship with them. Preserving those relationships can be good for referrals and future business, as well as making the time spent on the project more enjoyable and satisfying. Here are some suggestions to help you foster those important business relationships.”

Read his list of 10 tips that will help you develop and maintain client relationships.

Good consulting requires good communication

Takeaway: Don’t let a communication gaffe damage and possibly end a client relationship. Learn how to improve your communication skills.

Your technical abilities form only a small part of what you need to be successful as a consultant. Because your clients are all people (at least until the machines take over), skills in dealing with people can make or break any consulting engagement. One of the most important people skills you can acquire is the ability to communicate well.

Language proficiency

Let’s start with basic language skills. Recently, I worked on a project that required quite a bit of research. The available sources were severely limited, but I finally found an article by someone who had been there before and knew what he was doing. However, although the article was ostensibly written in English, the author’s grasp of the language was tentative at best. This made a difficult subject even harder to follow, so much so that if I’d had another resource available, I would have dropped this one. But I didn’t, so I fought through it and spent way too much time trying to make sense of every other sentence.

I’m not someone who thinks that everyone in the world should speak English. I like linguistic diversity — I know from experience that learning more than one language opens your mind to different ways of thinking. But in whatever language you choose or are required to communicate with your clients, you must be proficient. Consultants regularly bring new ideas that may be difficult for clients to comprehend. Don’t let language barriers make that even harder.

Language usage

Besides clearly transmitting your message, your use of language also affects your reputability. Even though the author of the article to which I referred above demonstrated a thorough knowledge of the subject matter, after reading the first few paragraphs, I might have been tempted to dismiss him as illiterate. Your use of language comprises a big part of your first impression on clients, especially if the first contact is not in person.

That doesn’t mean you should embellish your communication with lots of highly technical or obscure words (yes, I know I’m guilty of using obscure words). Words that appear designed to impress will usually have the opposite effect on smart listeners; your client may assume she is supposed to know what a specific term means, and she might find her lack of knowledge an embarrassment and be afraid to ask for the definition. This hampers communication rather than enhancing it.

Engagement

The key is to engage your audience — whether you’re speaking one-on-one or to a public gathering or you’re writing an email or a formal document. An informal, conversational style often helps to keep people interested. But there’s a big difference between using contractions, colloquialisms, and even the occasional bit of intentional bad grammar versus the unintentional mistakes that proceed from ignorance. The former keep people awake and engaged, while the latter merely present stumbling blocks to communication.

People attend better when they enjoy the process. It’s almost always good to sprinkle in some humor or colorful metaphors to make your subject more interesting for your audience. The most noxious tasting medicine can be made palatable by adding some sweetness, and even though that might mean that the recipient gets more sugar in their diet than they strictly need, the overall effect can be beneficial. Conversely, even the most fascinating subjects can be transformed into a Trail of Tears by a pedestrian presentation.

Engaging means tuning in to what your audience is thinking, and speaking directly to them. You need to listen at least as much as you’re talking. If you have a final answer on any subject, you can’t really have a conversation about it — you can only dictate what you believe, and people don’t like dictators even when they’re right. As with iteration in software development, exchanging information and ideas helps all parties explore the subject matter more fully — even if you disagree. So I find it helpful to promote the attitude that there are no sacred ideas — any conclusion is fair game for renewed discussion if that seems helpful to any party. That doesn’t mean that you have to question the meaning of existence or whether computers can actually work before you can tackle more immediate problems — but you should be willing to explore any assumptions that might blind-side you and your client. In my experience, most people usually err on the side of inflexibility — as if their answers, once concluded, should never again be questioned.

Remember, the goal is not to bring others around to your way of thinking; the goal is to find the best solution, even if that means having to admit you were wrong. Good communicators inspire others to think about a subject and contribute to the general understanding about it.

How to improve your communication skills

As with most endeavors, practice makes perfect. We live in an era where you can put content on the Web and get feedback from around the world. Use that to your advantage. Write regularly on a blog, or submit articles and white papers for online publication. Look for opportunities to speak in public. If you’re not yet ready for the stage, maybe think about joining a local Toastmasters to hone your skills first.

Every time you write an email or speak in person or on the phone, consider how best to get your message across to clients. Often, fewer words say more — and that means it’s time for me to shut up.

Keep clients in the loop with a good communication plan

When is an IT consulting project like an oil change? This isn’t a riddle — it’s a brainstorm I had recently while watching the team at my local Instant Lube perform an oil change on my car. Let me describe the process.

As I drove up to the garage, the manager came out and guided me into the oil change bay. When I stepped out of my car, he walked up to me and smiled, and then began to explain to me how they were going to service my automobile. He described the different grades of service available, but never tried to sell me on one or the other — he just gave me the information I needed so I could make a decision about which service was appropriate for me. The team that would work on my car surrounded it and began to shout to each other: “Car in bay one,” “Opening hood in bay one,” “Testing coolant in bay one,” and “Tire pressure 40 in bay one.”

It wasn’t clear to me immediately why the guy emptying the old oil from my car needed to know that another guy was putting air in my tires. As all this activity went on, the manager, rather than trying to shuffle me into the waiting room, chatted with me about the work his team was doing on my car, explaining to me why they constantly communicated their progress to each other as they worked. “It helps each member of the team know how much time they have left, and helps them make sure that we do everything we’re supposed to do for each car. It helps them check each other, so no one forgets to put back the oil plug or the fluid cap.”

Inform clients at every opportunity

Why am I going into this length about my oil change? Because I’ve had my oil changed before at other places that didn’t go through this process. I’ve faced surly, uncommunicative mechanics who pulled out my air filter — which was in fine condition — and tried to talk me into changing it, and then looked at me like I was a bug when I declined. I’ve been to lube stations where I came out not knowing what they had done, or if they’d even actually changed my oil at all. The stark contrast between those other lube shops and this one was so striking that I’m sure I’ll be a customer for life, as long as they keep communicating with me the way they did.

How does this relate to consulting? I’m no mechanic, so I can’t judge the quality of the work that my mechanics do except by the results and by the quality of the attention I receive. Many of our consulting clients are in the same boat. They’re looking to us to deliver excellence in our technical specialty, but in order to differentiate ourselves from other service providers, we need to do more. We need to make their experience with us the best, most comfortable event possible.

This superior experience, in most instances, boils down to superior communications. Helping our clients understand the process they’re about to go through, just like the store manager did with me; communicating the status of the job as it progresses — both within the team and with the client — like the lube team did; acting as an advisor, not a salesman: All these things add up to an enhanced experience for the client.

Characteristics of a good communication plan

For all these reasons, I insist that in consulting teams I work with, every engagement includes a communication plan. A good communication plan can bring value to the engagement in a number of ways: It helps set customer expectations, acts as an assurance factor that bolsters the client’s confidence, builds consensus around the project and helps market its benefits, and gives the client and the various constituencies in the organization an opportunity to give feedback on the results of our efforts.

Let’s delve into these factors a bit and discuss the ways a communication program can make our lives as consultants easier and more fruitful.

• Set customer expectations. One of the most important jobs any project manager or consultant must do is to manage the expectations of the client community. From the very first meeting, and all through the project, we need to be sure that we’re communicating clearly what we’ve committed to deliver, what we can (and can’t) achieve, and what our role is and what the clients’ or subcontractors’ roles are, and we need to be sure that we’re setting budgetary and schedule expectations. This is not a one-time event, but a constant activity. We need to help adjust client expectations as we deliver, so that as circumstances affect our schedule, budget, or deliverables, we’ve clearly communicated that to the client, thereby avoiding any misunderstandings.
• Assurance factors. As I described in one of my previous columns on pricing scenarios, reassuring the client as we go is a critical consulting skill. In all engagements, but especially in time and materials projects, the client can be nervous or uneasy, wondering if we’re on track, running into any hidden snags, or running over budget or schedule. By building in formal assurance factors, like status reports and team reviews, we short-circuit any concerns that may be building up, and get a reputation as a “straight shooter.” For clients who have internal intranets, I’ll often set up a project Web site where interested team members can keep tabs on the project’s progress.
• Build consensus. Effective users of technology have one characteristic in common: they seek consensus, rather than running IT projects out of the boardroom or the executive suite. Communications plans that include believable, meaningful descriptions of the features and benefits of the new technology go a long way toward building buy-in across the organization. For large-scale projects, town hall meetings or “lunch-and-learn” sessions can help create a feeling of inclusion and participation throughout the organization.
• Market its benefits. Experienced consultants, just like good internal IT professionals, know that a major part of their job is selling the features and benefits of the technology they are implementing. I’ve been involved in projects that went as far as designing logos and “brand names” for the project in order to raise awareness and comfort inside the organization with the new effort. New technology is often disruptive; it’s our responsibility as business advisors to help our clients convince their troops that there is a reason for the disruption.
• Client feedback. One-way communication, from the top down, doesn’t cut it anymore. Modern associates in the client enterprise are likely to resist any effort that doesn’t give them a chance to participate in the process. Project communication plans should include an avenue for feedback from the affected staff members. The project Web site mentioned above is one avenue, as are project e-mail and voice mail suggestion boxes, where constituents can voice their opinions and express their concerns.

The corollary with the oil change has one other significance: Communications are the lubricant that every IT project needs in order to run smoothly.

Have you created a sure-fire communication plan that keeps you and your clients happy? If so, what does it entail? Let us know in the forums.

Should you charge more when you don't know what you're doing?

Takeaway: In the discussion following last week’s post Seven reasons to turn down business, TechRepublic member burntfinger1 said: If I don’t have a particular skill set and the client wants me to “do the best you can,” my price goes way up and I tell the client why. If I’m going to [...]

In the discussion following last week’s post Seven reasons to turn down business, TechRepublic member burntfinger1 said:

If I don’t have a particular skill set and the client wants me to “do the best you can,” my price goes way up and I tell the client why. If I’m going to have to pay someone to fix up a mess I made I have to be able to afford it.

After I questioned this policy, he confirmed that the higher rate is by the hour, not by the job. His rationale, it seems, is to create price resistance against clients pushing work on him that is beyond his abilities — and to cover his costs of subcontracting it out if they succeed in putting him in over his head.

There may be some merit to this from the client’s perspective, too. If the work lies outside the consultant’s experience, it could simply be more difficult or esoteric material, which would mean that its production creates a higher value than other more common tasks.

On the other hand, this could also represent a gap in the skill set of the consultant. In that case, the client isn’t receiving the same value for the work performed as when the consultant is operating within his/her technical comfort zone.

I’ve always tried to base my rates on the value provided to the client. I’ve been known to reduce my rate when I’m learning a lot of new technologies, because some of that time represents value to me in the form of education.

As Earl Nightingale always used to say, the money you receive will be in direct proportion to the service you provide. I might insert the word “perceived” right before “service,” but the principle still holds. Clients will continue to pay what they think your services are worth, and no more. So it seems counterintuitive to me that you would charge more for work that you can’t perform as well. Unless, of course, the intent is to drive away that business.

How about you?

Manage expectations with IT consulting clients

Takeaway: Most veteran IT consultants have war stories about failed expectations. Chip Camden offers pointers on how you can appropriately manage expectations with your clients.

The IT consulting path can be a bumpy one. The very things that make it interesting, such as the variety of clients and projects, can also result in sudden surprises. I like some surprises, like “Happy Birthday!” or “You’ve won a million dollars!” but I’m not as fond of surprises like “That isn’t what we wanted” or “We haven’t paid you.”

Ninety-nine times out of a hundred, unpleasant surprises result from failing to manage expectations. Either the consultant was blissfully unaware of something the client expected of them, or the consultant expected something from the client but failed to make that clear. Here are pointers on appropriately managing expectations with your client.

Communicate. The number one cause for failed expectations is never expressing them. Don’t assume that just because a given practice is customary in the industry, your client will automatically follow it. Plainly state your rules of engagement — payment terms, scheduling expectations, requirements gathering, feedback, etc. Conversely, your client may be incorrectly assuming that you understand what they expect from you, so make sure that you know their expectations by regularly asking appropriate questions. Solicit a constant feedback loop.

Prioritize. In business, some expectations are crucial, while others are “nice to have.” Make sure that you and your client understand which are which. Of course you’ll try to provide everything they want, but if push comes to shove, you might have to drop something or at least delay it. When you have an agreement with your client about that contingency, nobody gets shocked by the outcome.

Document. You just had a great phone conversation with your client — you nailed down all the key plans for the project, and you’re certain that you and the client are on the same page. Before you jump into development, though, write it all down. Send an email detailing all the points you agreed on. Likewise, any terms that you expect from your client need to be in writing. Verbal agreements may be legally binding, but proving that the agreement ever existed is another matter.

Follow up. Just because you communicated and documented the expectations on both sides, never assume that it’s a done deal. Revisit expectations on a regular basis and make revisions where necessary. Verify that expectations are being met on both sides. If not, immediately work with your client to get back on track. Even the smallest disappointment needs to be acknowledged and dealt with — otherwise it can grow into a bigger problem.

Give and take. Nobody is perfect. We all overcommit sometimes. Unforeseen circumstances occasionally prevent fulfillment of our obligations. So after identifying a failure to meet expectations, you should make a new plan with more realistic goals, or stick to the same plan after acknowledging an unavoidable exception. Just don’t let failure become the norm.

Insist on respect. When someone fails to meet our expectations, a large part of our disappointment comes from the perception that they didn’t care about what was important to us. If you’ve ever had a client pay late without ever saying a word, you can relate to that feeling of disappointment. Furthermore, when one party tries to lower expectations, it can feel like a slap in the face, depending on how it’s presented. In order to effectively manage expectations, you must start and end with respect. Start by identifying what’s really important to your client and to you, and then work together to see how much of that you can achieve together. When addressing a failure, it helps to start by reiterating why the expectation was important to you — that will often suggest a remedy.

Share your war stories about failed expectations and what you did about them.

Evaluate your consulting expertise using the Dreyfus model

Takeaway: Do you qualify for the title of expert consultant based on the Dreyfus model of skill acquisition? Read about the model’s five stages of learning to find out.

To say that “a comment from Chad Perrin got me thinking” is redundant, but this one made me wonder how many consultants who call themselves experts could qualify for that title based on the Dreyfus model of skill acquisition. Let’s examine the five stages of learning put forth in a 1980 paper (PDF) by Stuart E. Dreyfus and Hubert L. Dreyfus, focusing on self-evaluation:

1. Novice

In this phase, the subject cannot exercise “discretionary judgment” but must instead exercise “rigid adherence to taught rules and plans.” I’m reminded of the time as a newbie operator when I deleted a day’s work for the cashiers because those were the documented steps for starting them up in the morning. The novice does not know the domain well enough to generate any creative ideas of his/her own, or even question whether a rule applies in a given situation. At least, that’s supposed to be the reason. How often do we simply follow rote procedures without understanding why they’re in place? Sure, it’s easier that way — just get the job done and move on. But you can’t really call yourself a consultant if you don’t at least consider evaluating your client’s methods.

2. Advanced beginner

At this stage, the subject has learned to apply some principles situationally, but they don’t understand the relative importance of the various aspects of their work, nor do they have a comprehensive picture of how they fit together. I think this often applies to consultants. We like to have our bits well-defined and separated from the work of others. Too many inter-dependencies can make it impossible to get anything accomplished. Clearly separating concerns is a good thing, but as consultants we need to understand how those bits work towards larger goals — otherwise the client might as well hire a $12 an hour guy off the web. Understanding the big picture often makes the difference between producing what the client requested instead of what they need.

3. Competent

The subject begins to perceive how their work relates to larger goals. They’re able to plan their own work, and deal with multiple activities. To cope, they develop routines — and here’s where many consultants get stuck. After getting burned once or twice for failing to cover some base, they develop a fool-proof routine to prevent that from happening again, then swear their eternal allegiance to it. While it’s wise to have routine procedures that keep you from having to remember or figure out what to do each time you encounter the same situation, it’s important to recognize that not all situations are the same. So when you start lecturing yourself with “I will never again…” or “I will always…”, remember that you’re placing that safety net at the expense of abdicating the right to think situationally.

4. Proficient

The subject perceives the whole domain as a system, including “deviations from the normal pattern” that inevitably occur. He/she can prioritize, because the relative importance of aspects of the system have become apparent to them. They use adaptable maxims to guide their decisions, rather than hard and fast rules. Many people incorrectly label this level “expert”. Certainly, the proficient person seems like a wizard to the competent (or below), able to almost magically know the right course of action. But the magic is only a more thorough knowledge of the domain than the competent person has. As we shall see, true expertise is something different.

5. Expert

This person has so internalized their understanding of the domain that they have no need for rules, guidelines, or maxims. While they can appreciate the need for organizational rules or the situational truth of maxims, they don’t use them to determine their own course of action because they can grok the entire situation and choose the path that leads to the desired outcome. “Rules are made to be broken”, but you have to know when and how to break them. More importantly, the expert can go beyond what the project accomplishes, to think about what else could be possible. To what new paths does this effort open access? The vast majority of what’s called innovation occurs by accident — but the expert actively seeks it. Not just innovating for the sake of innovation, though — it’s always because the path could lead to new opportunities that benefit the business.

Think about your relationships with your clients. Where do you fit in this scale, and under what circumstances? What steps could you take to get closer to number 5, or to get a stronger foothold therein? How would your clients react? If they would discourage you from “thinking too much”, then maybe they didn’t really mean to hire a consultant.

What it takes to be a consulting expert

Takeaway: IT consultants who want to be considered experts should stop worrying about their shortcomings and start talking about their experiences, insights, and aptitudes.

In the Consultant Journal article “Who you calling an expert?”, Andréa Coutu writes:

Becoming a small business or independent consultant may seem out of reach to some of you because you just don’t think you’re enough of an expert to be a consultant.

Let me tell you right now that becoming an expert is not as complicated as it sounds. When you’re a consultant, you are offering your clients something of value –- your expertise. But expertise doesn’t have to mean that you are the world’s foremost expert in your field. No, expertise just means that you have more insights than your client does on your given area of expertise.

I prefer a cautious humility over blind hubris. It’s good to know your limitations. But as Andréa points out, it’s easy to let an awareness of your shortcomings keep you from accomplishing all that you might be able to do for your clients. From the novice’s perspective, an expert may look like a demi-god and his experiences like the labors of Hercules. From the other side, though, the distance between novice and expert does not seem nearly so far.

For some of the technologies for which I provide consulting services, I’ve been working with those technologies for two or three decades. I’ve helped to create some of these, and participated in their design and development over the years. On those technologies, I can call myself an expert, as you’d be hard pressed to find another person on the planet better qualified to consult in them.

But I also consult in technologies that I have not personally influenced, and in which I possess sometimes less than a year’s experience. Yet I am still able to provide an almost equivalent value to my clients in these other technologies in which I could reasonably qualify as a novice. How can that be?

You might chalk it up to cumulative experience in the field, which allows me to recognize patterns of development wherever they occur and apply general principles of due diligence and good design. I’ll grant that’s a factor, but I don’t think it’s the whole story, or even an interesting part of it. In fact, the opposite has often been the case: the old way of doing things often hampers rather than helps. Adapting to new paradigms requires me to retain a youthful perspective on development, rather than getting set in my ways. I need to be a learner more often than a teacher.

Expertise is more about your ability to learn than it is about what you already know. Our industry changes so rapidly that yesterday’s knowledge may be good for perspective, a good war story, or a Wikipedia article, but it isn’t going to meet your client’s needs without adapting to their present problems. As a result, we’re all novices.

Back to what Andréa said: to offer expertise to your client, all you need is to “have more insights than your client does.” The first step in gaining those insights is to find out what you do and do not know. Next, determine what you need to know in order to be helpful. You probably don’t have to know it all. For instance, if your client wants to use a specific programming language to create their new product, you may not need to have a thorough understanding of that language’s underlying implementation of hashes. Sure, it might help, but how much? Much more important would be a good grasp of its available idioms for whatever you’re trying to do. Identify sources for any information you lack, and explore those sources until you know where to look for anything you need. Finally, play with the technology. Satisfy your curiosity on any questions that you can anticipate.

Malcolm Gladwell has become famous for (among other things) the 10,000-hour rule: If you want to become an expert at something, you need to put 10,000 hours into it. That’s about five years, full time. While that amount of time would probably qualify you for most technologies in most people’s eyes, I prefer to think of expertise on a scale relative to your client’s needs. As Andréa said, “more insights than your client (has).” Perhaps instead of marketing our “expertise,” we should be talking instead about our experiences, insights, and aptitudes.

Assess the damage before resurrecting a failed project

Takeaway: Salvaging a failed project is never easy. The best approach for figuring where to start rebuilding is to understand what went wrong.

When you’re hired to pick up the pieces of a failed project and move forward, it can be overwhelming to wrap your head around where to start. The key to coming up with answers to questions about how you’re going to be able to resurrect the project is to ask a lot of questions. These are the series of steps I follow to prepare for getting a project back on track. price it well because you’re likely to face a few unknowns and more than a few risks.

Investigate what went wrong

Study the project documentation
I’ve been in this situation four times, and it’s always interesting to investigate what happened to get the project from point A to point F. You should try to obtain project documentation (including the original requirements, budget information, project schedules, and status reports), though it may be difficult to get your hands on this information. In the four instances when I’ve taken over failed projects, I’ve only had access to documentation once.

Talk to the previous project lead or sponsor
It’s even more interesting if the person who managed the failed attempt is available to meet with you. Even though the former project manager will likely claim the project going off the rails wasn’t his fault, you can still gather a lot of useful information by speaking to him. If that person isn’t willing to discuss the project, you might see what you can find out from the project sponsor.

Engage the SMEs
The subject matter experts (SMEs) are your next point of contact. Unless the previous consultant was completely out of touch and avoided the SMEs altogether (which would be a clue as to why the project failed), then they were likely part of the failed project and can offer insight into what happened and be good resources for information, requirements, and basic needs going forward. In my experience, the SMEs want you to succeed, especially if they happen to be some of the users who will benefit from the implementation.
Map out an action plan

After you collect all of this background information, it’s time to map out your course of action for the project. You should create a detailed project schedule and document how and when meetings and communication will occur. It’s also important to conduct risk planning; the project sponsor should understand about the cost and the need for risk planning given the project’s history of failure.

Overall, you need to show that you’ve learned from the mistakes that were made on this project, and that you don’t intend to repeat them.

Bonus tip: Be sure to price this engagement high enough for various unknowns and risks you’ll likely face.