The Interaction Between IT Architects and Project Managers

I also maintain a blog on enterprise architecture and IT topics, and a debate within the architect blogosphere has ensused about the tension and interactions between architects and project managers. I posted my initial commentary on that topic and you can view it here.

How 'Percent-Complete' Is That Task Again?

Students in my project management classes get treated to a mini-rant about the percent-complete method of measuring when a task or set of them are completed or not. So I thought I'd share it with the blogosphere. Simply put, this is a poor technique to measure task completion, and always has been.

Why? For starters, its too ambiguous. How many times have you sat in project status meetings and heard claims that some front-burner, critical task is '90% complete' and stays there for months? Or that the last 10% of some task takes much longer to complete than was originally scheduled? Happens all the time, and I plead guilty in my software developer past to doing the same thing.

This technique suffers from a number of problems beyond ambiguity: the 'system' it creates is easily gamed by project staff; the neophytes on your team usually don't have the experience and judgement to make reliable estimates in this fashion; and if you're using earned value analysis or other PMO-style metrics to track project progress, you can't come up with metrics that have much value or believability.

The ambigutiy is maddening at times. Can you put 80% of a software application into go-live production? Does 95% of a new product development have any immediate economic value to the business? Of course not, so why are we using this measurement?

Here's another way to look at this issue: tasks fall into two categories, with no gray area between them - they are complete, or they are not. No middle ground. No percentages. No promises that the remaining 6% will be completed by next Wednesday. This technique scares the hell out of people because it is a binary measurement of truth-in-project-status, and such accountability may be too harsh in the politics of a lot of organizations.

But the technique is very, very effective. If you decide not to use this in your daily/weekly project management scheme with your teams, I strongly suggest that you do it anyway for your own enlightenment on where things really stand with your projects.

Some caveats on using this technique are in order. First, the tasks need to be broken down into time-manageable chunks, such as a few days or, at most, a couple of weeks, without giving the appearance of micro-mangement to the project teams. This is particularly true in knowledge-intensive work like engineering, programming, research & development, etc. If you let tasks go on too long, you may be in for a number of rude surprises where task deadlines are coming up and you find out last minute that they won't be complete, with the corresponding risk and damage to the project schedule.

Then, you should make it perfectly clear to your team what the basis of task completion is. No hidden agendas, no unfair comparisions. If you explicitly state up front what the measures of task completeness and success are, you'll encounter little pushback from teams, other than the ones who know how to hide behind percent-complete random guesses.

As I mentioned before, if the above is politically unpalatable in your organization, you can make this assessment from your current project data by marking all tasks between 0 and 99% complete as 'not done' and those at 100% as 'done,' and see where you really stand. Believe me, you will probably find a number of issues to take action on when you make this type of assessment.

Accountibility and truth - such wonderful concepts.

What Cell Phone Cameras Are Really Good For

Wondering what that camera phone is good for other than taking some goofy photos of the kids and spouse or getting it confiscated at the health club? Behold the following:


Yeah, that's right: they are really good at taking pictures of whiteboards. Which saves you oodles of time not copying it down on paper. Even better, with most camera phones you can e-mail the photo to your account as an attachment, then use it in a document or convert it to some other format like Word, Powerpoint, or MS Project. I've saved e-mailed whiteboard photos do my hard drive as JPG files, then slapped them unedited into a Word document with text and sent them off as e-mail to other groups. Very simple and effective.

A caveat: if your cell camera has low resolution, be prepared to edit the e-mailed file to get the words to show correctly - usually increasing the size of the images works fine if you've taken the pictures properly. Once you get your e-mailed photo, saving it as a JPG or GIF file helps in using the image in other documentation.

I knew these camera phones would eventually be good for doing something other than chatting...:)

The WORST Type of Project Manager

In addition to working as a project manager and teaching the subject at UW-Milwaukee, I also work in IT as an enterprise and data architect. For the non-IT types reading this, enterprise architects deal with the specific relationships between business strategy and processes and how those are realized with information technologies.

I usually have no problems working in teams in a non-PM role as I love IT architecture as much as I do project management. Also, I never offer PMs managing the teams I'm on project management advice unless they ask me for it (they often do ask, but some don't). Finally, I don't overly critique PMs to the team or management unless: a) asked; or b) things are so bad that I have to rant and vent in the hope of getting to a positive outcome for the project and the project team.

OK, my motives might not be entirely altruistic. After all, I am running a business, and projects are revenue, and good, completed projects are good, long-term referals, so yes, I get something out of this too.

Anyway, I recently had the misfortune to run into a pretty poor project manager who has one key strength - excellent political skills. On the poor side, the guy can't do scheduling and come up with accurate milestone dates to save his butt. His method of scheduling primarily comes down to this: 1) Here's the totally aggressive and unrealistic date I promised the sponsor, but didn't let you in on until just now; and 2) match all of your work to this date, regardless of any other committments (business & personal) that you have.

Then, of course, as the dates get routinely blown by the project team, he distances himself more and more from the project until its clear that it has no project manager, or one steps up into the breech to either complete the work or shut the project down as gracefully as possible. We were in the middle of blowing some significant milestones on a project I was doing with him when he entered my office all bent out of shape and declared "WHAT shall WE DO about THESE DATES??"

After I motioned to him to take a seat - I leaned over, got about a foot from his face, and said very evenly but making no mistake about my intent: "You are the project manager, and its time that you started acting like one. You are the first one to take credit when things go well, and are nowhere to be found when they don't. This is YOUR PROJECT. If you want me to take over PM, then let's go see [the CIO] and make arrangements. I'll also make sure to inform him of WHY we're suggesting this change. If you think that you can lay all of the problems on this project with the project team, I strongly suggest that you think again because believe me, the outcome will not be in your favor."

He looked at me like I shot his dog. That's what narcissistic types do, I guess. It's all about him and things just can't survive without him. We'll see.

We ended up completing that project and delivering on its major milestone 6 months later than planned, and looking back, that 6 month slip was the realistic date. Narcissistic PM went on to head an even larger, more expensive project (in part due to his excellent political and BS skills) but his bad habits caught up with him. He was the cause for a huge revolt on his project team within 9 months, and severe slippage in cost and schedule on the project. He was summarily canned as PM and likewise from the company a few months later in a downsizing cutback.

Wonder if he learned anything from these experiences, or if it will always be our fault he didn't succeed.

I've Seen This Movie Before and Know the Ending

Once again, a client is heading for a project train wreck. A project that was back-burner for many months now is front and center because of significant regulatory issues (i.e. fines) that will crop up in July if this project is not implemented, or fails to deliver.

Projects based on regulatory or government-mandated edicts are strange ducks. You can't over- or under-prioritize them with respect to other projects because, for the most part, you have to do them to become or remain compliant, and stay in business. In short, they just happen, and when they hit an organization, it usually has the force of an anvil dropped off the 50th floor.

Not so this time. The issues and impact were known months ago, but management incorrectly gambled that they'd get a waiver (they've had several already), and you know, with budgets tight and all, it just didn't register on the priority scale.

Well, they bet wrong. Again. This situation is compounded by the fact that two major projects have significant (read: affects their revenue) milestones coming up in the next 60 days, and critical resources from those projects are being siphoned off to deal with the 'new' regulatory project. The PMs involved feel like transplant surgeons who have installed 3 livers into an alcoholic that keeps right on drinking. Now the patient needs a fourth liver - and will most likely keep right on partying. It gets old, fast.

Call it hindsight, but the time to have started worrying about the regulatory issues was last summer or spring, when they were known. It's too late to address these issues with 6 months to go, and it's pre-ordained that the organization will undergo significant pain because even if the regulatory project succeeds on-time, the two other revenue-based projects will not (as originally projected) because of resource shifts and adding resources will have little effect on current schedules and will drive up costs regardless.

Unfortunately, there are no PM scenarios or methodology to counteract bad managerial judgments. The PMs will 'take one for the team' for the 4th or 5th time, and it would not surprise me in the least if some of these fine folks (and key players on their teams) vote with their feet in a few months and begin drawing paychecks somewhere else.

Where they will most certainly be more appreciated than they are now.