Showing posts with label consulting. Show all posts
Showing posts with label consulting. Show all posts

Wednesday, November 21, 2007

What is your IT specialty?

Even though the name of this blog is “IT Consultant,” I never call myself by that title. As TechRepublic member sheila said, everybody needs a specialization — and “IT” is way too broad a term for the consulting services I provide. The Information Technology Association of America (ITAA) site provides a document containing 32 pages of definitions for “Information Technology. ” I’m particularly fond of Ray Bjorklund’s (apparently unintentionally) recursive version at the bottom of page 7:

The statutory definition of information technology, as amplified by OMB A-11, includes services and support services related to the implementation and sustainment of IT.

IT has come to represent virtually anything connected with computers, and nearly everything is connected to computers these days. So I usually refer to myself as a “software development consultant,” because I typically consult for software companies, providing strategies for their future development. Shannon, the other regular author of this blog, focuses on project management instead. And I’m sure that our audience (that’s you) covers a much broader spectrum of specialties beneath the wide umbrella of “IT.” Or maybe some of you are left out in the rain.

I’m curious to know more about our readers, so I’d like for you to respond to the following informal poll. Please also add a comment to the discussion to tell us about your specific expertise — especially if it doesn’t fit into one of the categories below (which would seem unlikely, given that one of the categories is “something else”).

Three tricks for dealing with the holidays as a consulting project manager

Travel costs have skyrocketed. No one is available to finish off those last ugly bits of work before the budgets run out. Everyone seems to want to hang out with their families, generally in inaccessible places, rather than burn the midnight oil finishing off our wildly out of scope project work.

It’s got to be holiday season again. The time of cheer. The time of eggnog and happy children. The time when nothing gets done because everyone would rather be somewhere else. Don’t get me wrong — I like the holidays as much as everyone else. But enough is enough already.

As a project manager tasked with cleaning up loose ends during the holidays, I tend to utilize three tricks to keep things moving.

First up: Pare it down
The simplest thing to do is use the constrained resources, limited budgets, and dwindling time to finally get people to prioritize project activities. As laid back as things seem, there are still a few items of very important work to be done. Now that we only have a few weeks left, we can sometimes find out what they are.

This is, to be honest, probably the one and only time I use time-boxing as a client facing tool. I show a simple grid with the weeks down one side and the resources across the top. Each box contains five days (or two or three, depending on the holiday week) of available work time. I then give the client a list of the open items and ask for help fitting things in.

No one likes the results but we all end up with a clearer picture of what we want to spend money on. That is, I guess, the point.

Next up: Shore it up
The hardest thing for an introvert to do is get out there and mingle. However, this is the one time of year during which a traveling team might possibly come together. Even a static team of IT professionals, one which does not travel much, will start to come out of their cubes as the holidays reach their inevitable ‘nog-hazed climax.

As the project manager, its our job to reinforce the social as well as activity-focused roles in the team. We need to talk, talk, talk, introduce topics of conversation, and guide the discussions which occur spontaneously away from work topics.

“Away from work topics?” Yes. There will be plenty of time for people to thrash out all the problems of the last year and 366 days with next year’s issues. Got to love leap years.

Finally: Twist it around
Everyone expects the project manager to arrange for a wing’s luncheon and at least one early day off to go drink some beer. We need to do these things, but we should also spend a few minutes to come up with something creative. Better yet, if there’s an extrovert on the team, make him come up with something creative to do.

The only rule here is to throw out the predictable. No team-building exercises, leadership seminars, or “development opportunities.” Probably my best received event was the time I scheduled a full week of vendor presentations. We learned a bit about upcoming technologies, had a great time chatting between and through meetings, and got some nice lunches out of it. All, naturally, in the name of project progress.

Wednesday, October 31, 2007

Three ways project managers give in to threat

We live in a corporate environment (and indeed a social one) where the fear of personal, financial, or political harm counts for more than the honest calculation of risk. Economists are slowly starting to key onto this with their calculations of “perceived risk”; priests, theologians, and mothers everywhere probably realized this somewhere around the time humans started to speak. As project managers, we have to deal not only with the threat we face ourselves, but also the threats an organization’s management react to and the threats which press down upon our project resources.

All of these threats wear down our enthusiasm and determination. They also prevent us from doing what’s right rather than what will shield us from fear. We worry more about doing what our bosses want, what our executives might want, and what ever will keep people’s eyes off of our project than honestly trying to get the job done on time, under budget, and within the requirements.

In our role as project managers we give in to threat in a variety of ways. The most prominent of these is to misreport data about misalignments in resources, time, or function requests from the project. We can also obscure the work we do behind layers and layers of data, hide issues as they occur, and place ourselves in a situation where we control all of the inflowing information, thereby shaping our perception of reality so that it no longer matches with what is really going on.

Misreporting happens all the time. Most of us can do simple calculations or look at a calendar and tell when things fall behind. We know from personal experience that we do not have enough time or that our resources are stretched too thin. Yet we say nothing. We become afraid that the project will be canceled or our contracts terminated if we do not do exactly what we are told when we are told it. It happens often enough, in fact, that the threat has some teeth in it.

Another failure, one that I’ve fallen into from time to time myself, involves generating too much reporting data. On one hand it looks like we’ve accomplished something. Hundreds of reports showing that we’ve done something with our time, certainly look better than an entire day spent on the phone talking with people and having nothing tangible to show for it. Just as importantly, the volume of the information shared insures that we can control the conversations around it. We direct people to the “important” parts, and subtly shade the rest to support what we want to say.

Hiding issues is another favorite failing of mine. It’s easy to talk about how all issues should be escalated to management. It’s simple to say “Why yes, we should have talked about this earlier”. But we also know that people want projects to be quiet and perfect. Perturbations along the project path do nothing to endear a project manager to his managers. Indeed, they are usually seen as failures on the part of the project manager, and can become grounds for dismissal when the inevitable witch-hunt begins.

The last failing is probably the most insidious. As project managers it is our responsibility to report project status. When people want answers about a project, they come to us. It’s easy to make all information flow up to us first, for vetting and perception management, before it reaches anyone else. Logical, even. Unfortunately this kind of activity actively leads those who report to us to taint the truth. They tell us what we want to hear or what they think will make us happy rather than what we really need to know. We then pass on the bad information in total confidence, now unaware of events in our own project environment.

I don’t have any easy answers for dealing with threat. We don’t talk much about the importance of feelings in business or how vital a role our emotions play in our decision making processes.