I was in an important meeting and the project team pretty much knew that a certain person wasn’t carrying their weight. This person wasn’t a complete let down…but could do more. During the course of our project meeting an issue was raised as to why a task had not been completed. This person became defensive and started pointing fingers and making excuses. I lost it. A normally mild manner person, I let him have it. I gave him the what for and how come. However, I was out of line and spent hours in one on one meetings apologizing to this person and the rest of the team. There is a time to kick someone in the pants and a way to do it. My way that day was wrong. It costs our team more time in apologizing then this person not completing their task. The bottom line is we have to play the game with the team that we have. There isn’t always time to replace someone and many times there isn’t anyone else available…period. My advice…if you aren’t getting the job done, own it and move on. People respect that more than excuses. Secondly, be slow to speak or you may make a situation worse. I know, because I did
Negotiating and Managing Project Expectations
One of the many factors in project cost overruns is due to setting unreasonable expectations. Whether working as a consultant outside a company or as a project manager within a company, all too often we become “yes” men to secure a deal or please superiors. We may win in the short term by getting the job or by delaying management’s wrath by telling them what they want to hear, but, in the long run, both scenarios are losers. As a consultant you land the gig and wind up with bad word of mouth advertising as being late and over budget. As an internal project manager you develop a reputation of being unreliable and/or overly optimistic. Instead, be real and upfront about duration and costs of expected projects. Give pushback to help set reasonable expectations. Maybe someone else will promise the moon? You should challenge competitors’ unreasonable assertions. You may still wind up losing the deal, but in the long run you will maintain your reputation and eventually land more deals because of it. Short term pain for long term gain is tough in this economy. What is your word worth and where do you go to get your reputation back?
The Gantt Chart and Daily Project Coordination
All project managers have used or at least heard of a Gantt chart. The Gantt chart was created by Henry Gantt around 1910 and still widely used today. It was used in major projects like the Hoover Dam. Henry Gantt designed the Gantt chart to help manage project scheduling and work progress. If you read his book, Work, Wages, and Profits (1916), you will note that Gantt believed it was imperative to communicate daily schedules to key players and by not doing so rendered schedules useless. Gantt thought it was important to be a project coordinator, to coordinate activities, and reduce conflicts. I think this is an important and often overlooked part of being a project manager. We often look at the larger picture and fail to identify “Daily” influences that cause project slowdowns. We should have daily expectations and identify barriers to those expectations each and every day.
Reference:
Gantt, H. L. (1916). Work, wages, and profits. San Diego, California: University of California Libraries.
My list of project risks
There are at least a hundred reasons projects fail. Expect anything from vague requirements to budget shortages to waning passions to unreasonable project schedules. All novice mistakes… But we can’t all be experts on every topic. About the best we can do is identify the most common areas for failure, and discuss these with the team. At least the team will be aware.
Here’s a quick starter list. You’ll probably have to make it a little more diplomatic before presenting it to your group. “:)
1. Newbies don’t know how long things actually take.
2. Unfamiliar technologies need extra research time.
3. Virtual development teams don’t communicate the same as in-house.
4. Team members without a passion for the product won’t perform.
5. Vaguely defined projects either go on forever or burn up in debate.
6. Projects without top-level commitment get lost in the minutia.
7. If the company doesn’t need it bad enough, it will fail.
8. Pick only two: Cost, Quality, or Time. Let the third fall where it may.
–newshirt
IT is Backed Up – Forever
Consider this dilemma… The IT department is backed up for six months. It can’t take on any new projects for that time. Not even a little 4 – 8 hour database installation. With a log jam like that, they can’t get anything new in.
Management comes along with a new product evaluation. Problem is, they need IT to set up a new SQL database so they can test the system. Oops, can’t do it. There’s a six month waiting list, and nobody get to the head of the line.
So, management can’t evaluate the product. Even a product they desperately need. IT has failed the company in a big way. The frustrating thing is that most of those IT projects are probably lower priority, or impossible to complete. Incompetence has allowed such projects to block real work.
The only real solution to an issue like this is “better generaling.” I.e. better planners who know roadkill when they see it, and pitch it off the road so it can’t block the real projects. That takes a smart person with a little experience. Gain a skill like that (and a hundred others), and you suddenly become a valued member of the team.
–ray
IT Snow Days
eWeek did a little editorial on “IT Snow Days.” (See link below.) Anybody out there read eWeek? It sure is collapsing slowly – down to 42 pages, and no more Spencer Katt. The competitor InfoWorld went out about a year back. Now, I suspect eWeek will follow. I guess it’s pretty hard to get IT folks interested in industry news. Anyway… Here’s the article.
http://blogs.eweek.com/up_for_discussion/content/it_management/it_product_snow_days.html
I liked the article because it sympathizes with IT managers who are being hit with economic snowstorms. It’s really hard these days. Mostly for me, it’s hard staying motivated when everything around me is crumbling. Anybody feel that way? There will be a few snow days to make up for when good times come again. That’s for sure.
–newshirt
Our Projects Are Always Late
I talked with an IT professional over the weekend. This person lamented over their constantly late projects. I told them about Standard Time®, and how it tracks project time. They loved the idea! But continued the lament, claiming they would never use such a product.
I just stood there stunned. Why not? I didn’t ask, but assumed it had something to do with the economy, frozen purchases, and what not…
But I just kept thinking… Wouldn’t Standard Time pay for itself? Late projects, especially persistently late ones costs companies money. Lots of it. A few thousand dollars for software would tighten up those schedules and force the company into compliance. The ROI would be 3X or more. So, why not use it?
I suspect it’s unfamiliarity. People simply don’t know how to use time tracking and project management products. No training. No familiarity. Nobody’s firing them for late projects, so they keep doing what comes naturally. Oh well… 🙁
–newshirt
My Dead Project. What Went Wrong?
Last night I attended a party at an old friend’s house. After small-talking my way around the deck, I hooked up with some old acquaintances, with whom I had participated in a software project. The gig we shared had taken place back in 1999, in Atlanta. It was one of those 90’s love-fest dot-com jobs.
While sipping cokes and gobbling slices of homemade pie, we discussed the project’s failings. “What went wrong?” I asked my colleagues.
“I think it was the fault of the CEO,” one said. “He just had no experience, and wasted all the money.”
“No, the development organization was all messed up,” the second said. “The lead engineer kept jumping in and changing everything I did.”
“Well, I think they spent all their money on marketing before they even had a product to sell,” I put in. “You have to make some sales and get customer feedback before you can spend millions on marketing. Don’t you think?”
The discussion heated up for the better part of an hour, and I realized that none of us, even ten years later, knew exactly where the faults were. Who had messed up? What had gone wrong? Why hadn’t we succeeded in shipping a product and engaged the sales channel. None of us knew for certain, yet we all saw some pretty gross mistakes.
That really got me thinking… Sometimes project failures are not as easy to diagnose as one might think. Even by salty old dogs like us. And everybody has their own opinions. Think about that the next time your project bites the dust. Or before it does.
–ray
Project Overload: Too Many Requests
I once read a bizarre statement, written by an overloaded IT manager. He was complaining about the heavy workload his executive management was throwing on him. Here is what he said:
When a new project request comes down, I just ignore it. I ignore it until management makes it clear my job depends upon it.
Wow! That’s revealing! Evidently, this poor soul is so swamped with exciting new projects that he is forced to ignore the bulk of them. I can vividly see how these superfluous demands go down.
First, the executives get a great idea. Yeah! Let’s restructure the customer database to maximize the communication [read: spam] we send out. We’ll get some great sales!
The project is handed off to Harold in IT. “He’ll make it happen,” the suits say.
Harold comes in Monday morning, sorts through 400 spams, and finds the outlandish request. He rolls his eyes and drops it into the “Oh Boy!” folder. And then he checks the ESPN stats.
The execs never give the project another thought. They just go off and reinvent the company ten more times, dumping an equal number of requests on poor Harold. And he ignores them all. He doesn’t have time for the fun. He’s got real work to do.
Am I off? Got it all wrong? Honestly, I don’t think so. I’ve seen numerous projects like this get swept under the rug. Execs don’t run the show, the little guy does…
–ray
Engineers Hide Risks
Every project manager knows he must identify project risks, document them, and resolve each one. In other words, he must learn what could jeapardize the duration, budget, or quality of his project. If you don’t, the project may fly off the tracks and you’ll look bad, or worse.
Problem is, your engineers are hiding those risks from you. The fictional dialogue below shows how it happens. It is a faux conversation between your project manager and one of the engineers on the team.
PM: “I love your new designs! This project is really coming along.”
Eng: “Uh-huh.” (hoping to be left alone.)
PM: “Do you think you’ll be finished by October. Big deadline you know!”
Eng: “Of course.” (barely lifting his head.)
PM: “Any risks or unknowns? How about that integration task?”
Eng: “Nothing I can’t handle.” (peering deeply into the montor.)
Engineer-boy has two problems. First, he’s a little too independant to admit he needs help. Secondly, he won’t risk the tarnish to his stellar reputation. No white-shirt, tie-bearing, non-pierced PM will ever get him to crack. He’ll work all-nighters if he has to, or so he tells himself.
–newshirt