You simply cannot manage what you don’t understand, nor can you delegate it or request updates on it.  Understand and manage to results, not to line items on a task list.

One of the most important aspects of a project is completely understanding what the end of the project will look like.  It’s the only way to recognize the finish line.  Just as important is recognizing what the completed deliverable of a given task is.  How do you know when you can really tell if a task is completed?  How do you, as a worker, recognize when you have completed what the client really wants?

Identifying a clear vision of what a completed deliverable looks like is vital.  I recommend, for a project, that not only do you include a complete scope in your project’s charter, but that you create a document that provides a description of what the final deliverable is, is not, and what measurables will determine if it has been delivered or not.  When you discuss tasks during the process of working on a project, always make sure that you clarify with both the deliverer and the receiver of the task’s results what the deliverable looks like.  Keep your footprints clear in the sand as you go.

How many of you have heard a developer say this at one point or another:

“Why on earth would they want it to do that?”

Modern requirements gathering has become a very sterile task- identify what must be done.  Don’t get into the weeds.  Describe the problem.  Let the developer solve the problem.  Where this goes astray is that, like the worker on the assembly line who inserts tab A into slot B and passes the item down the line, the developer is simply pulling a lever to make it exactly as described.  They have no idea what the goal is, so they can’t troubleshoot, they can’t add value, they can’t even tell if it does what the user intended- which is often different to what the user said to the business analyst.

A good business analyst can get at what the user’s intentions are.  The problem that I’ve found is that often the business analyst may know what the user’s intentions are, but he has no idea how the existing system is solving the user’s problems.  What the business analyst usually has is how the user thinks the software solves the user’s problems.  There may be large, significant chunks of logic hidden deep in the system that have broad implications, none of which the user or the business analyst is aware of.

1. The company needs more manpower or expertise in some area
2. They have a brilliant idea:  Hire consultants!
3. Consultants come in to help.  Since the company either hasn’t the manpower or expertise to do the project, they hand the consultants what they know and have, which isn’t much.
4. Consultants start trying to do the job right (you hope).  They hold meetings, ask questions, gather requirements, start work…
5. Company loses patience.  Needs product quickly, doesn’t want to spend money.
6. Consultants give up on being allowed to do this right.  They hurry.  Requirements gathering sometimes suffers; writing documentation reduces drastically.
7. Consultants hit company’s deadline (if you’re lucky).  Company asks consultants to turn over documentation and do a knowledge transfer to internal staff.  Company gives consultants a meeting (usually a couple of hours) to transfer everything the company’s needs to know about multi-month project to poor guy who may never have even heard of the consultant’s project.
8. Consultant does so and leaves.  Company struggles to maintain what the consultant has done.  Company swears never to hire consultants again.
9. Six months later, more consultants are engaged to redo what the last consultants did.

Sound familiar?  Some of this may sound extreme (or maybe not extreme enough, depending on your experience).  It happens all the time though.  Consultants are a double-edged sword.

A double-edged sword, though, in the right hands, is a very powerful weapon.  So how do you transition from an accident waiting to happen to a grand swordmaster?

The secret, as with most things in life, is practice and discipline.  Here’s tips for succeeding with Consultants:

Plan ahead:  You should have a plan in place as to what activities you believe the consultants need to do when they arrive and for the early period of the engagement at least.  You should go over this plan with the consultants beforehand and gain buy-in, adjust as needed, etc.  Frankly, if you don’t know what you’re going to do with them before they arrive, you shouldn’t be bringing them in yet.

Share Expectations:  First thing when you bring consultants in, give them a quantifiable, measurable explanation of what you need and what you expect of them.  Leave as few things vague as possible.  This will save time on both sides, as it should answer a lot of their questions, and if they weren’t going to ask questions, it will save you the pain of any incorrect assumptions they might have made.

Set the Standard:  Create a system of standards for the type of work the consultants will be doing- coding standards, database standards, data analysis standards, business analysis standards, etc.  You should already have these in place for your existing staff (and if not, you should really be correcting that).  Give these standards to the consultants when they come in-house as part of your expectations.  Just tell them up front:  “This is the way we do things here.  Consistency is important to us, as it helps us manage things long-term.  We appreciate any improvements you can suggest and will consider adding them to our standards, but we do expect you to follow the standards.”  Your people really will appreciate the consistency later, as it will help make the consultant’s work more familiar right away.

Review, Review, Review:  Conduct very regular reviews- code reviews, if they’re developers, document reviews, whatever is appropriate to the work at hand.  It may seem tedious, but a one hour review every week will help save you weeks of work later.  It will help keep the consultant on track with your expectations, assure they do stay within your standards, and the reviews will help you have a better grasp of what they’ve done later.

Feedback is everything:  Don’t review to grade.  Review to provide feedback.  Your consultants want to do the right work.  Regular checking in and providing constructive feedback will help them go in the right direction- and again, it will help you be more familiar with what they’ve done later, when you have to maintain it yourself.

Participation is encouraged:  Some people don’t like consultants to spend too much time chatting with the existing staff, coming to meetings, etc.  After all, they’re (usually) paid by the hour.  The more you can involve the consultants with your culture, though, and let them participate in informal sharing of information, the more they will learn to help them produce better products for you.  The information that they share in turn will help your staff better maintain their work after they’re gone as well.  There’s also countless little things that your staff can learn from the consultant- a quick infusion of new “tricks of the trade” is always good for the shop.

Do you have other useful tips for managing consultants?  Drop them in the comments!

Here’s some advice: if you don’t know why things are the way they are, ask questions. If you don’t agree with the answers you receive, don’t be afraid to challenge the policy. Challenge it until you either get a good answer or get the changes needed for the business.

The rules that make up your company’s policies were written by and are owned by employees of your company, employees just like you. If confronted with good reasons and solid evidence why the rules should be different than they are, it is very possible that whoever is responsible for making that policy will rewrite and improve it. It’s possible that there may not even be an owner anymore; sometimes “We’ve always done it this way” is a terrible enemy. Even if you don’t get the change you seek, you may get it waived in certain cases where it no longer makes sense and get your work through faster. The change to the rules that you spark may improve the company overall.

What if you find out that the rule had a good point? Did you waste your time bucking against bureaucracy? Not at all. The explanation of the rule will teach you more about the business. It may explain processes in a context that you’ve never considered. They may teach you something about the company and about business that explains why the rules are the way they are. The change in your work as a result of this new understanding will be worth the effort.

Never be afraid to challenge. One way or another, you have everything to gain.

Let’s consider a basic example.  In company X, wait time for customers calling in for support is way up.  The call center is packed; there’s no room to add staff.  Even if there was, there’s no budget to do so.  The busy season for customers is coming up; everyone knows that call volumes will be up soon.

So what happens?  Management announces that they will start monitoring call times.  They want to see the amount of time per call reduced.  Armed with this mandate, help desk managers start communicating this to helpdesk workers.  Get the call times down; you will be graded.

What will this lead to?  In my experience, this will usually lead to the helpdesk workers working harder to end the call and working less hard at properly solving customer problems.  The result will be more repeat callers and more frustrated customers.  In the mean time, call times will go down.  Call volume will go up.  Everyone will point to the fact that they correctly predicted that call volume will go up and pat themselves on the back for successfully getting call times down.  In the meantime, they’re ruining their relationship with their customers, and they don’t even realize it.

What was the right thing to do here?  One good solution is to launch a specific effort to improve the analysis going on at the helpdesk, so that you can reduce call times and reduce repeat callers.  Look for ways to make your people more efficient- don’t just mandate it with a statistic.

The lesson here is be careful what you monitor and how you monitor it.  Monitoring a statistic will usually make the statistic better, but it will not typically solve any actual business problems.  Monitoring should always be accompanied by a specific plan to do what you are monitoring better.

The reason to bother is obvious:  to note things worth remembering.  Most projects span a considerable amount of time.  Building a new piece of software can span months or years.  People also usually are involved in multiple projects.  Remembering the details of each project is a real challenge.  When confusion eventually sets in on what was decided, who said what, who committed to do what, and so on, meeting notes become invaluable.

Considering that, when is the last time you reviewed your meeting notes?  Who is writing them?  Are they capturing all of the valid points?  Are they capturing all of the decisions made?  The commitments?  Are they capturing any details that you don’t remember happening?  If so, are you following up on those details to ensure that they’re valid?

He who writes history defines history.  So too with meeting notes.  Once enough time has past that people do not remember every detail of a given meeting, it’s meeting notes become reality, not the meeting itself.  Set up a regular time each week to review meeting notes from that week and ensure accuracy.  Commit to spend 30 minutes once a week to read everything.  Add addendums as needed and check all points that you have questions on for validity.  If you don’t, it can bite you later.

Why do this? Here’s three reasons, for starters:

1) It’s a big win with your employees if you succeed- it shows that you care about making their lives better

2) If they hate doing it, they probably aren’t doing it well. If the product is lousy, whoever gets the product either will appreciate the improvements made or don’t need the product in the first place.

3) Eliminating tasks frees up your workers to do bigger and better things.

When you’re done, take the results to your management. Present the processes your team have eliminated or improved. Present it to your peers as well, and challenge them to do the same. You’ll be surprised at how much dead weight your company can cut away. It may even start an initiative to clean up by your executive management. Cutting outmoded tasks is an important type of expense cutting that not only recovers manpower and resources for your company, but contributes to employee morale.

1.  People Skills Matter
The number one key in business is trust.  Money is at stake.  People’s careers are at stake.  Entering into business with any unit outside your control- a partner, a client, a vendor, another department even- is scary business.  Winning trust is not just important for making a sale- it’s important for the ongoing process.  If the business owner trusts you, they may buy your product, but what about their IT staff?  Their project manager?  If these folks don’t trust you, they will make your implementation a nightmare, as they try to make certain that your implementation is successful in your organization- by calling all the shots to ensure you do things their way, even if they have no expertise on your software.  If their support organization does not trust you, they will seek their own solutions to problems rather than working with you to make their implementation better.  Trust is needed all the way across the board.

This is where people skills matter most.  Your organization must be able to establish an ongoing rapport at all levels.  Your sales people must be able to reach a good rapport with their business decision makers.  Your implementations and technical people have to be able to establish a good rapport with their IT staff.  Your support organization must establish a good rapport with theirs.  From department to department, this principle still applies- you must have good rapport at all of the contact points in your organization.  This even applies the other way- if the people who you have communicating with your customers and partners can’t establish trust with the people inside your organization, they will be seen as ‘pandering to the clients’, and you’ll face internal problems.

People skills are invaluable in building trust.  Building trust is one of the most important skills in business, and one of the most difficult to teach.  Your ‘face time’ people in your organization should be chosen as much for the ability to make friends with anyone and exhibits good trust-building and trust-maintaining skills as any other skill needed for the position.  Relationships matter.

2.  Initiative Matters
A good rapport is the beginning of any business relationship.  Now that you have the relationship started, though, you have to deliver.  Friendship is about many things.  Business is not.  It’s about the bottom line.  Making money.  Creating value.  Promise what you can deliver, work hard, and follow through.  Anyone involved in communicating who says “Well, I lined them up, now you guys take care of them” is not the following through.
 
3.  Focus Matters
An important part of being able to deliver is not over-promising and under-delivering. To get there, you have to focus on the right things.  Out of all the markets, all the customers in that market, all the ideas we have, all the projects we have on deck, which ones most deserve my resources?  What has the best bang-for-buck?  If you take on more work than you can execute on, you will fail at all your commitments.  The more different customers you involve when you finally fail, the more customers you will lose because of your lack of focus.  You will constantly be tempted to reach for the next ring.  You will be tempted to enter new, additional markets.  To paraphrase the old wine commercial, attack no market before it’s time.  Focus.  Complete the job at hand before you start a new one.  Identify your most important targets and knock the ball out of the park.  Everything that you promise, commit to it and fulfill that commitment.

If you do this, once you conquer the market at hand, once you please the customer or partner at hand, you will receive recognition and help when you proceed to your next challenge- help in form of income from clients, word of mouth, reputation, all the things that matter and reinforce why you are the best choice out there.

4.  Responsibility Matters
When you make a mistake, own that mistake.  Make it right with the customer.  Acknowledge the customer’s concerns with your mistake and the possibility of more mistakes.  Fix the problem, identify how to prevent it in the future, and communicate.  Most importantly, do it in that order.  Don’t promise that “it will never happen again” if you have no idea what you are going to do to prevent it yet.  Failing, promising, then failing again just ruins your reputation.  Now you’re a failure *and* a liar.  Don’t panic when you make a mistake; mistakes happen.  Resolve the mistake and move on.

5.  New Opportunities Matter
Expansion is always easiest down the path of least resistance.  Your existing customers are the easiest to sell additional products to.  Your existing markets are easiest to sell in.  Your existing products are easiest to expand.

Look for synergies between your products and offerings.  When possible, increase them.  Yes, I am as tired as anyone of the word synergy- but, in this case, it applies.  If you are remotely focused, your existing products, projects, process improvements, projects… they should all have a crossover somewhere, or be near having a crossover.  Look for ways to take advantage of these things to increase revenue and increase the value of your products.  Product A may not have any value to people who buy Product B as is, but there may be something you can enhance about either Product A or Product B that brings them together and makes them both more valuable.  Voila, you’ve created a new market for your products for a small amount of effort, and in an area where you have a high chance of success- with existing customers, in a market where you have a presence already.

How does this apply to your internal departments?  In many ways, it is the same thing- you probably have existing products, processes and projects that increase productivity and value to your company.  Look for ways to marry these up to increase value to the company with less effort than having to create whole new projects from scratch.  Keep your maintenance down and your focus high as you expand.  Familiarity with the existing product also helps you drive internal adoption easily.

6.  Service Matters
Everyone is in the service business in some way.  If your job in the company is to do something that you can identify no customers for, then I would suggest that what you do for the company has no value.  If you maintain something, there are people who depend on that something- those people are your customers.  If you write documentation, you have two customers- those who distribute it, and those who use it.  Put your customers first and deliver.  If you are in management, make sure all of your employees are delivering.  Everyone should be focused on their customers.  At the same time, the customer is *not* always right.  If maintaining a customer is costing you more than the value that the customer is bringing to you, then sometimes the right business decision is to reduce your market and let that one go, so that you can focus on your value customers.