Four Values of Social Networking

Or, why LinkedIn matters.  And maybe Facebook.  But not MySpace.

The Self-Project: Jerry Seinfeld’s Productivity Secret

Learning to be do lots from the guy who wrote the show about nothing.

The Self-Project: MBA in a Page- a Simple Guide to All Major Management Theories

Where to find out about all those management theories people talk about (but seldom practice)

Five Articles You Should Read Before You Powerpoint Again

Help with making your powerpoint less pointy

PM-Fu: Seven Steps to Gaining Buy-in to Change

Getting help getting people on board

Corporate GTD: Recognizing What Not To Do

How to help find direction in a sea of work to do

The Self-Project: Six Building Blocks of a Quality Reputation

Building a better you

The Self-Project: 25 Tips to Being Happier at Work

Building a happier and better you

Soapbox Time: What’s the Integrity Level of Your Business?

Building a better company for the better and happier you to work in

PM-Fu: How Much Detail Is Enough?

Learn how to keep your Work Breakdown Structure out of the weeds

Enjoy!

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.

The end of the business quarter typically marks a reporting milestone for the accounting and finance folks. For better or worse, it’s become a time when the measuring sticks come out. Businesses have come to measure progress in 90-day sprints. Think about some of these goals we end up saddling ourselves with:

• Close the sale before end of quarter! -why?  Will the money be worth less next week?
• Wrap up the project so we can get the billing in on this quarter  -again, I ask, why?  Does money become worth less next week?  If it shows up this quarter, doesn’t that just take away from next quarter?
• We need to make a buy decision this quarter, because we have budget now  -aha, maybe this is it, if money magically has a shelf life of 90 days…

Some of these decisions do, I realize have real financial implications to the accounting and finance world, so please don’t fill the comments with explanation.  I work for the NASBA- I do know something  about accounting.  My point is this:  too many times in business we make decisions or we hurry work and get sloppy results, not because there’s a business imperative, but because there’s a perceived financial imperative driven by the need to look good on paper.

This happens in projects as well.  Sometimes something comes up in a project that warrants changing the schedule or cost- the company’s future is at stake on the project, and it can’t be done wrong- and yet PMs will escalate and try to force the hand of the people doing the work because they don’t want to look bad by having a note on the PMO’s executive summary for that month saying that they’re off-schedule or over budget.

My point is this:  is it ever a good decision to allow how you look on a report drive cutting corners and hurrying processes?  Of course you can’t just ignore reports.  They’re there for a reason, and it’s a good reason.  Still, you must consider trends over time and how you will be judged long-term.  If a sale or project close out after the quarter mark, yes, it robs this quarter, but didn’t you get a nice bump in the next quarter as a result?  Even if you cross fiscal years, is that really so wrong?

Don’t let pressures to look good drive you to make poor long term decisions- not for your department, your company, or your project.  Keep your eye on the long-term ball and stick to strategy and delivering successfully.  Delivering a shoddy product early has never been a successful strategy with customers- delivering the right solution at the right time does.  They don’t care about your quarterly report; they care about receiving quality.  Companies succeed over years and decades, not 90 day sprints.

PM-Fu: Keep Your Eye On The Ball

Advice on keeping your project on track by sticking to your scope.

Writing Right: The Art of the Status Report

How to write the stately Status Report.

The Self-Project: Get to Know the Folks That Can Help

Why it’s okay to talk to the janitor while you’re in the office late at night.

UF Postings Past: Three Ways to Destroy Morale

Three things you should never do when leading people.  Unless you want to.  Don’t say I didn’t warn you though.

Project Management found on Mars!

Where this led next is the interesting thing- my team assumed that it was a bad thing and started trying to solve the “problem”, not be excited about the opportunity.  At first, I thougth there were some terrible implications of the idea that I had not thought of, and so I started digging in, trying to figure out what the problem was.  All in all, it took us all about ten minutes to arrive at the fact that I trying to communicate something positive to them, not a problem.

So what went wrong here?  Business speak.  Our company has fallen into the trap of trying to be positive about things.  Business people commonly say “opportunity” when they mean problem.  In fact, I’ve heard them correct each other in meetings to intentionally make the substitution.  What effect has this led to?  Has it made problems truly become opportunities?  No.  Has it made people more optimistic and positive?  No.  What it has done is changed the meaning of the word “opportunity” in our lexicon to mean “problem”, which now leaves everyone in our company with the challenge of how to communicate about real opportunity now, because we can’t use that word anymore.

As humorous as this sounds, the problem is real.  When I related this story to a few of my colleagues in management and said “so what do we say when we want to talk about an opportunity now?”, no one had an answer.  We’ve successfully sabotaged our ability to relate important information within our own company.  We probably are not the only ones.  Try relating this anecdote around your own company and see what kind of conversations you end up having about it.

I’ve written before on the dangers of business jargon before.  This is an honest, serious problem creeping into the business world.  The one thing that businesses cannot afford to do poorly is communicate.  Understanding jargon is important.  Don’t propogate its use.

Anyone else have any similar experiences?  Better yet, anyone know a better way to talk about opportunities?

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 what was happening on Undocumented Features for the third week of August 2007:
PM-Fu:  Organizational Planning when using Matrix-based Project Management
Great article.  Long title.  We’ve improved on that. 

Management Magic 101- How to Delegate Well

The Self-Project: Simplifying Your To-Do Lists To Get More Done

PMing on the cheap: OpenProj free PM software

Always Strive for the Best! (and Never Get Anything Done)

PM-Fu: Keep Your Eye On The Ball

And that, folks, was the first week of UF on the new blog.  Enjoy!