Project Management (RSS)

Bad IT Project Management

My sister-in-law recently passed the PMP certification (congratulations Heather!). I'm waiting for a call from her asking if we need to add resources.


The resources comment above is a joke, but it isn't really that funny. It's indicative of my decades of experience with bad IT project managers.

I believe and hope I have worked with some of the worst project managers on the planet. Why do I hope? I'd hate to think anyone has had to deal with folks worse than the poor project managers I've dealt with.

As I type, we're experiencing a heat wave in Farmville, Virginia. It was 107 degrees Fahrenheit here yesterday. It's the "dog days of summer", as my Granny used to call them.

Somehwere, you will find 30 or more push mowers lined up wheel-to-wheel along one axis of a lawn. On command, the 30+ operators will start their mowers. On cue, they will push them across the lawn, maintaining the wheel-to-wheel alignment, cutting the entire area in one pass.

This, my friend, is the home of an IT project manager.


My experiences have led me to a couple thoughts:

  • Frederick Brook's should be required reading for all project managers.
  • Proof of callouses should be required for the application process.

(The same can be said for MBAs, but that's for another post...)

Inspired by the book, Brook's Law states "Adding manpower to a late software project makes it later." It is perhaps best summed up by the following statement by Brooks himself: "The bearing of a child takes nine months, no matter how many women are assigned."

As an IT professional, you can learn to detect when you're about to be "managed". I share the following indicators and advice from my years of experience:

"Do we need to add more resources?" This question in and of itself is harmless. It's actually the way project managers greet each other and has no more meaning to ordinary folk than "How are you doing today?" or "How about this weather?"

The best answer to this question is a non-answer. After years of trying to correctly answer this (as though it were a meaningful question), I stumbled across an answer that works for me: "I don't know." Why does this work so well? The last thing a bad IT project manager wants to do is make a decision - at least one traceable to them.

"I am (or used-to-be) a software developer." If you hear this, you're in trouble. Big, big trouble. My advice to you is to vacate the project - and the premises - as quickly as possible. This isn't a fire evacuation, it's a bomb evacuation. You may wish to consider jumping out a window if you're on or below the third floor.

Why? You are dealing with a person who believes they were promoted because they were such a good developer. Mind you, this is true in less than 25% of my experience. And even then, odds are their resume includes COBOL or they aren't nearly the project manager they believe themselves to be. At best you have 1/3rd of a 25% chance that you're working for someone who knows a definition for delegate - a definition that isn't "someone who attends a convention."

The truth of the matter is this person was likely promoted before they could delay or otherwise further damage the software project to which they were assigned.

"What do I tell my boss (or the stakeholders)?" This question is the prelude to a demand. Your answer isn't important, the demand in the mind of the IT project manager is important. And that demand is for you to do something no sane developer would ever do.

There are a couple options. If you're feeling froggy, you can document the fact you were asked to take this ridiculous course of action by your IT project manager, and then do it. Be sure to address the issue in writing and as soon as possible. CC someone else - anyone else. If you can CC the project managers' boss without looking like you're trying to make them look stupid, that's best. If not, CC someone else at your level on the development team (and allow the bad IT project manager to continue their work of making themselves look stupid unassisted).

Note: Never BCC. BCC'ing the boss is the equivalent of placing a bold, red, flashing banner across the top of your message which states "I'M INSECURE". The boss will get this message, loud and clear. Go ahead and CC them if you believe it's warranted - those dogs need to wake up eventually.

Make sure it's in writing and someone else sees it - that's the point.

The other option is to simply ignore it and do what you know to be right and good. There's risk here too. Some bad IT project managers will call in bigger dogs to shout you down. It's good to have your mugshot and name on a book somewhere if you're going to exercise this option.

"Umm yeah. I'm going to need you to come in Saturday. Sunday's not looking good either..." People are people. Bad IT project managers don't get that. They call people "resources". People aren't resources, we use resources, but we're separate and distinct from resources. People are people.


Bad IT project managers are the reason we have IT Project Leads. After all, someone who knows what they're talking about needs to have some authority if any software project is to stand a chance of succeeding.

:{> Andy

PS - This post inspired a new category at Applied Team System: Expensive Management Practices - gotta love the acronym. :{>

Technorati Tags: Project Management IT Software Development

eScrum

Microsoft recently released a !

eScrum works with Team Foundation Server, so you'll need your own TFS server (you can build your own Team Foundation Virtual Server free!) to use this cool tool.

Scrum is one of the simplest and most visual of the Agile methodologies to implement. I've been privilieged to introduce Scrum into several large enterprises in the past couple years. It's just an awesome methodology!

:{> Andy

Technorati Tags: Scrum eScrum Team Foundation Server

Gatekeeper or Roadblock? Part 2

Over a year ago I wrote a post entitled Gatekeeper or Roadblock?

At the time I was working as a Production and Development DBA for a small shop. People would show up with requests that sounded legitmate to me. Usually these requests would take 30 minutes of my time and provide data to an individual or team that they could use to continue their work for days or weeks.

But the oddest thing would happen. My boss would happen by and ask what I was working on. When I told my boss what I was working on, my boss would inevitably frown. Then my boss would look cross and say something akin to "You should not be doing that for him / them." You may think I'm exagerrating, but I assure you I am not.

Hence the post.

Fast forward some...

I'm doing some consulting for a large-ish IT team for a large-ish company. Team members can't find things. They cannot connect remotely to work from home or while on vacation or away for training or business trips. A lot of stuff that Just Works at most IT departments simply doesn't work here. And no one can figure out why.

As a result, the IT department morale is dropping faster than the Congressional approval numbers because no one can get away from the office for more than a fraction of a weekend. Talented people have been recruited and paid an excellent salary with excellent benefits (including lots of unused vacation). These folks stick around for six months or so and then leave - often for equal or less pay and benefits.

Word is getting out on this place locally. Recruiting efforts are moving farther and farther away.

Network performance is awesome, but very little is actually able to run on the network due to "security policies" (hence the stellar performance). The network department consists of Bill and his very-high-turnover network engineering staff.

Bill's been with the company for years. If you ask him, he'll tell you he "keeps things running around here" and "doesn't know what those colleges are teaching kids these days - none of 'em are worth a tinker's damn."

A long time ago, Bill cobbled together a solution that exceeded management's expectations. He saved the company hundreds of thousands of dollars in consulting and implementation costs. His network did everything those high-falootin' college brats said there's would do, and it didn't cost the company anything other than what they were going to pay Bill anyway. "Just doin' my job," Bill answered when asked about it by an executive. The executive was so impressed, he basically promised Bill a job for as long as he wanted to work there.

Now.

The system Bill put in place did, in fact, meet the immediate needs of the company. And it didn't cost as much as the consultant-proposed system.

But it also won't scale. At all. Ever.

Bill's learned this. He's tried to make it do more, but the system simply won't.

Bill has a few options.

  • He could go to training, learn about building scalable systems, and implement a better version of his solution. After all, everyone knows you need to spend 25% of your time training in IT just to keep up.
  • He could hire people with more recent experience and work with them to build a better version.
  • He could admit that although he thought his solution was better for the company, it was really just a short-term patch and they should've implemented the consultant's solution instead of his.

Ok, I put that last one in there to see if you were paying attention.

Instead, Bill has locked down the network so every possible wavelength of bandwidth is available for his out-scaled solution. He doesn't need training, he has tenure. A guarantee. He still has an executive's ear - an executive he helped get promoted by saving all that money all those years ago - an executive who both owes him and cannot afford to have the truth come out.

As new people rotate into the department and get close to discovering the issues with Bill's outdated solution that won't scale, they're summarily dismissed. The executive backs his every move. "Bill knows what he's doing. These kids obviously don't."

And so, things do not change.

Except - all things change eventually.

In this case, the company's marketshare dips to an all-time low as productivity remains steady at a 1998 level for Bill's company - while the competition begins gaining marketshare using systems that scale.

When rivals reach the same marketshare, executives muse "they're topped out now!" and wait for the inevitable. After all, if their system won't scale beyond this point, no one's will. Right?

And then the competition's system does continue to scale. And in a few years Bill's company is bought out by their competition and the innovative IT department of the purchasing firm curses Bill's old system as they try to work through the hacks to get at something that resembles business rules.

In the end, I suppose the executive and Bill both parachute out into the business world, seeking another hapless company to victimize. They're richer, no wiser, and have left talent-devastation in their wake as they unceremoniously ended, wrecked, or disillusioned dozens of careers.

What a depressing post! For a good laugh, you have to go here and read the post and comments - very funny.

:{> Andy

Technorati Tags: Gatekeeper Roadblock A sad sad tale

Free Diff/Merge Tool

SourceGear has released a snappy new diff / merge tool - and it's free!

More information is available at Eric Sink's blog - it's definitely worth a look!

:{> Andy

Technorati Tags: Free Diff Merge SourceGear Eric Sink

Notes On Project Success - Part 2, to Stake-Holders

Yesterday, I addressed Technologists regarding Project Success; today I address Stake-holders.

I have participated in projects that have succeeded and in projects that have failed. One thing I noticed about the failed projects: expectations were poorly - or not - managed.

What are examples of project expectations?

  • Functionality - when completed, the application / upgrade / database / server will allow me to perform xyz.
  • Time - how much time one expects to develop the functionality. Can also include a schedule for deliverables and / or milestones.
  • Expense - how much one expects to pay for the functionality.

As a stake-holder you know what you want. And you can probably communicate your expectations - using the three areas above as a guide - effectively. Issues arise when, for whatever reasons, there is a disconnect between your expectations and the those of the IT team tasked with performing the work.

I've witnessed several unsuccessful executive responses to the disconnect scenario:

  • "Ostritch" - ignoring the disconnect in hopes it will disappear with time.
  • "Gambler" - belief that there's a big score (project or technical break-through) just-around-the-corner that will save the day.
  • "Taskmaster" - belief that threatening people is the way to motivate them to work around challenges.
  • "More-Resources" - a firm belief that more resources can solve any problem known to humanity. (I often imagine these folks live in subdivisions and get their neighbors to help mow their lawns. In my mind I see forty push-mowers aligned wheel-to-wheel along one edge of a lawn. On signal, they all puch across the lawn, mowing it from end to end in a single pass...)

I worked for a company that decided to employ Performance-Based Management techniques to a successful team. They actually applied the concept company-wide, regardless of whether the teams were successful or not. In this particular flavor of PBO, 20% of employees were considered outstanding, 60% were satisfactory, and 20% were acceptable losses that the company would be better without. These numbers were set in stone and never changed.

My questions were:

  • Who failed? Did HR fail 80% of the time by hiring mediocre to poor employees? or did our management disillusion and de-motivate these people into their non-excellent state?
  • Are we, in effect, planning to never get better?

Statistical control works on processes, not people - at least not well on people.


So what is the solution?

Communication.

It's that simple. Executives have to either be approachable by the IT team or someone representing them, or you must appoint someone to be approachable in your stead. Leadership dynamics (or just plain scheduling issues) may require you to appoint someone. If so, try to find someone who speaks both business and technology.

Realize that sometimes you do not know what you do not know. I run a couple small corporations and have an appreciation for the amount of work involved in merely administering such an entity. I also know technology changes every day. It's difficult for anyone to keep up - especially if you're minding stock-holders, regulators, and the lot. We may have moved beyond the technology you understand. If we haven't, we will soon.

Either hire people you trust or trust the people you hire. If someone violates the trust, respond accordingly. But do everything within your power to exude trust-worthiness as well as trusting-ness.

For truly innovative people to be free to succeed, they must first be free to fail.

The best tools were once toys. IT professionals are notorious tinkerers. You will be astonished at the return on investment for a weekly-scheduled hour of "play time" for developers.

:{> Andy

Technorati Tags: Software projects Success Failure Technologists

Notes On Project Success - Part 1, to Technologists

There was a very interesting article posted not long ago at SQL Server Central by Janet Wong entitled My Projects Have Never Failed.

In the article, the author explains projects that experienced varying degrees of success for various reasons - but in all cases a disconnect existed between the end-user or customer expectations and the delivered product.

Personally, I consider these projects failures.

Here's why: The stake-holder or executive has this expectation. It may be very unrealistic, but they hold it nonetheless. They may be very educated people or not. They may understand technology or not. None of this impacts the fact that they hold expectations.

Q: Who's in charge of communicating realistic expectations?

A: Technology people.

Or at least a member of the technology team.

A good technology team has several moving parts and people fulfilling different roles.
Note: If you're a one-person-show, this post is not about you.

At least one person on the team needs to be customer-facing. That person needs to be an expert in communicating with business people who hold unrealistic expectations. Make no mistake: this is a talent and an art.

Good communicators are rare in life, rarer in business, and practically extinct in the technology sector. Most good communicators abandoned IT departments decades ago and moved into sales where they could enjoy salaries orders of magnitude beyond what IT departments will pay them. But I digress...

I don't blame my customers when their expectations go unmet - I blame myself. Had I communicated something better - or even differently - the outcome would likely have been better for everyone.


So here are some tips for communicating with project stake-holders / executives:

  • You may understand what you mean when you say "Third-Normal Form Relational Database" at a meeting with executives, but few of them will. It's not their job to understand - that's why they're paying you. Step up. If you cannot translate your conversation into executive-speak, let someone else do the talking. If your point is to embarrass the executives, you'll probably not try that at your next job.
  • Identify someone on your team (or add someone to your team) to serve as a point-of-contact to the executives. If your team has a project manager, they may be the best person to do this. I've also seen horrible project managers who exacerbate the problem with their own inability to communicate (or worse yet, take the side of the stake-holders and hang the development team out to dry).
  • Keep it short.
  • Keep it as simple as possible. Stake-holders and executives do not need to know the history of iterations you went through to arrive at your conclusion. Take it as a sign of confidence in your abilities that they accept your judgment on the matter.
  • Stake-holders and executives have different priorities from you and I technology people - remember that.
  • If you deliver quality late, no one remembers. If you deliver junk on time and under budget, no one forgets.
  • The old consulting axiom ever applies: Under-promise, over-deliver.

This is business. This isn't academia; you do not get to interpret your own results.

It's not a success unless they believe it to be a success.


Me, I've had projects fail. Some of them have been spectacular in the scope of their failure. To date, I've stepped up, admitted the failed status of the project along with my errors, and promptly moved to correct the issues. I've found excuses to be a waste of my and my customer's time.

Having a project fail is bad enough; failing to manage the failure takes it to the next level.

Remember, if you fix it, it will be ok.


Tomorrow, I address Stake-holders.

:{> Andy

Technorati Tags: Software projects Success Failure Technologists