Business Record - Iowa Biz

So this is it

Four and a half years ago, Drew McLellan approached me about a "new blogging opportunity" which would be bringing together some of the best business bloggers in Des Moines under one roof. It was going to be called Iowabiz.com and we'd each contribute 2-3 posts a month under our area of expertise.

I have to say, it's been a blast sharing my insights and thoughts about project management with you over this time. We've covered the appropriate ways to turn an idea into a real project, prioritize it, plan it out, write status reports about it, audit it, recover it, and close it out. We've talked about the human nature of projects, how some people will report a task as 100% complete when it's not, how to play office politics, what to do when restarting a dormant project. I've used holidays, family vacations, current events, politics, and movies to drive home my points.

But there's one last thing I need to cover: walking away.

I'm a strong proponent of "fit" between a project manager and a project. I've fired myself before on projects when I've realized I was not the best person to move a project forward. I've also removed myself when I saw I had take a project (or team) as far as I could, and it was time for fresh leadership. And I've said "no" to projects where I knew I could not add value or just would not enjoy the project.

Sometimes, you have to walk away from a project, to say no, to turn it down. Such is the way it is for my relationship with Iowabiz. Do I have more to say on the topic of project management? Oh yes, and you'll still see my insights pop up on my blog. Have I appreciated our conversation over the past few years? Tremendously! But now it's time for me to say "yes" to some new adventures in my life, and in order to do that, I feel compelled to say "no" to others; Iowabiz is one of those "others" to which I'll bid a fond farewell. (Stay tuned for the announcement about my replacement; I'm confident the topic of project management is going to soar to new heights, and I'm excited to pass the baton.)

I wanted to thank you all who have read these posts month after month. Some have commented; others have just read; occasionally, I receive an email or a comment on Facebook or Twitter. But I know you're out there. And I've appreciated you. Carpe Factum, my friends... in Iowa business... and in life.

- Timothy Johnson

But what about the rest of us?

I've spent a majority of my time writing for this blog, directing my posts toward project managers, trying to help you improve your project performance.

Project managers, you get to sit this one out.

This post is for everyone who works with project managers... primarily, the project team members.

You may be totally enamored with your project manager... you may think she/he is the most outstanding person on the planet, a savior for your project's success. Or you may wonder what they're smoking half the time... why do I have to do status reports? What's with this issues log? Another meeting... really? Why can't I just do stuff?

There's a reason for that. A great post by Richard Wilner compares project management to customer service. As a project team member, your job is to provide amazing customer service to the end stakeholders. It's also to provide the same outstanding customer service to your project manager (assuming s/he is competent and plays nice in the sandbox and has earned your respect). Wilner states three key points to this end:

1) You can’t manage what you can’t measure.  How are you measuring your team’s skills? How are you ensuring they match project requirements? Tight correlation here is the easiest way to create an effective, engaged team.

2) No one ever got fired for thrilling the customer.  How are you measuring and tracking customer satisfaction?  A short customer or stakeholder survey given at critical project milestones will help bring the picture into focus.

3) Be a good vendor and a good customer.  To properly deliver for your customer, your vendors must deliver.  As a customer, set your vendor up to succeed – pay them on time, fully define deliverables and dates as soon as they are known, and if your vendor readjusts expectations, make sure you pass that through to your customer.

To that end, I'll let the project managers start reading. I've used the attached contract for project managers to partner with their project teams.

Download Team Member Agreement

OK, everybody, now all together...

CARPE FACTUM!

- Timothy Johnson

How?

Over the past several years, I've talked a lot in this blog about answering the project management questions: why? when? and who?

As in... "Why are you tackling this project?"

Or... "When will task A occur in relation to task B?"

Or... "Who is working on this task?"

But now I think it's time to give you a little help on the HOW

As in... "How do I create a solid business case?"

Or... "How do I plan out a project?"

Or... "How do I report status honestly?"

Or... "How do I track issues?"

So for this post, quite simply, I'm just sharing some of my favorite templates. Nothing complex. Use them. Modify them. Test them. Make them work for you. Nothing magical here. Most project managers use some variation of these. Now they're yours for the taking.

Download Template Business Case

Download Template Project Planning Checklist

Download Template Status Report

Download Template Issues Log

So no cute project stories or amusing anecdotes this time around... just straightforward "how to" on the basics of project management.

- Tim Johnson

Insert Tab A into Slot B as shown in Figure C

We just finished a basement remodel at our house. The work was contracted out, but once all the contractors had left, it was my job to assemble book cases. After a quick jaunt to Ikea, it was time to hunker down and build stuff.

The thing I love about Ikea furniture is the ease of assembly. With a hammer, screw driver, and the ever-present, handy-dandy wrench included in most Ikea projects, putting stuff together is a snap.

Keep the tools simple.

A good lesson for a project manager. When I'm on a project, I always start with four basic tools: a solid project charter, a complete project plan, a constantly updated issues log, and a (weekly) status report.

With these four building blocks, I can add or subtract with ease, ensuring that the audience gets the information they need at the time they need it.

My good friend, Lisa DiTullio, compares this philosophy to ice cream: "Serve Vanilla for Success.  In spite of all the flavors offered, it's still the most popular." Try putting gummy worms on chocolate ice cream or fresh fruit on mint ice cream.... ICK. If the project documents are kept simple, one can modify with ease.

Recently I found a book of project forms while cleaning out my storage shed... it was two inches thick. Who has time for that?

So next time you're feeling the urge to put a project together, remember to keep the tools to a minimum and effectiveness to a maximum. (NOTE, Stay Tuned for templates of each of these tools.)

Turning Up the Heat

Wow, it's hot outside.

Not just "Iowa summer humid and toasty" ... it's just plain ol' HOT and STICKY.

For the record, I'm not a fan.

Sometimes our projects feel the heat as well, especially when a critical deadline or due date is approaching. People get testy, collars get loosened, sleeves get rolled up... and everyone knows the project manager means business.

But WHY do we feel the heat when a major deadline approaches?

The short answer: We're not confident we'll meet that deadline.

The longer answer is multi-faceted. At worst, somebody - either intentionally or unintentionally - has procrastinated.

Almost a quarter century into my career, I'm still not quite sure what causes procrastination on projects, especially if a (credible) timeline has been estimated AND communicated. One project recovery I was leading was constantly waiting on requirements from a horribly inept branch of the Federal Government. They procrastinated because their "leadership" was allergic to decision-making. And the excuses continued on down the line.

But what about those instances where there's nobody else to blame? Besides blatant laziness, there are a couple of reasons why your project stakeholders may be waiting until the last possible second:

According to a post by Tom Foster, he shared a conversation he had with a manager, who was concerned with the procrastination behaviors of her subordinate. According to her, he  "seems to stay away from, or procrastinate on all the projects that take time to plan out and work on. And then, it’s like he jams on the accelerator. He even told me that he works better under pressure, that last minute deadlines focus him better. I am beginning to think that he waits until the last minutes because that is the only time frame he thinks about.”

Some people are just wired to the last minute mentality (ask any high school teacher or college professor, if you do not believe me). Another possiblity is paralysis by analysis, or Ayd Instone calls it being a creative perfectionist. His post lists three "damning conditions":

• Not wanting to begin a task right now because you know it will take more time to complete, or at least to get stuck in to, than the time you think you have available now. What’s frightening about this is that sometimes we can write of whole days due to this feeling and yet each day has the same number of maximum hours.

• Not wanting to begin the task because you don’t feel like it at the moment. The conditions don’t feel right, you’re too tired or not motivated. We try to convince ourselves that we might feel like it later on in the day, or that evening, or after a cup of coffee or after some other postponing condition.

• Not wanting to begin the task now because you don’t have all the information, skill or equipment to get going with. This often leads into some irrelevant research which, although useful, isn’t good for motivation because at the end of the day nothing appears to have been achieved. This feeling is also a great trigger for spending both money and time looking for and buying extra resources and equipment in a vain hope that the new inventory will feel like progress has been made. It never does.

The tricks to overcoming procrastination on projects come down to some simple steps:

1. Have a plan - you don't know who's late with what if you have not sat down, identified tasks, sequenced them, estimated them, and resourced them. A solid project plan can prevent (or at least, mitigate) procrastination simply by documenting what needs to be there).
2. Plan for success - provide team members with the things they need (software, furniture, subject matter experts) to be successful. Brainstorm WITH THEM what the list contains. Then follow through on providing them with the REASONABLE items.
3. Resource intelligently - if it's a high risk task that cannot be done wrong or late), you'll be much better off making enemies by insisting the right people work on those tasks than you will by allowing the wrong people to work on the tasks and then miss the deadlines.
4. Communicate natural consequence (and follow through) - when tasks are late on my plans, I generally broadcast it to the masses. Team members generally don't like having their name cmmunicated with a late task, but it's a great motivator. In general, make sure others know what will happen if they miss a deadline.

 

 

Dealing with procrastination proactively can save your projects countless headaches and deadlines near. And it can keep the heat down on your projects. And right now, avoiding any kind of heat is a good thing.

'Cause, Baby, You're a Firework...

Happy Independence Day!

One of my favorite parts of this day is coming up in a matter of hours: FIREWORKS! I love the sounds, colors, and (if I'm close enough) smells of the pyrotechnics. What always fascinates me is the coordinatoin of the shows, knowing when to light which firework, the delay, the direction, the angle, the details.

Project management is a lot like that. Fireworks would be easy if the coordinator only had to light one at a time, in no particular order, whenever s/he felt like it. But to the outside spectator, it would come off as boring and mundane. The fireworks coordinator has to know how each explosive would perform in relation to those around it.

In the same way, project managers have to know how each component of their project - tasks, people, organizational constraints - will perform in various circumstances. According to Ari Tikka of PM Hut, Project managers have to ask the right questions of the right people at the right time to figure out what's going to happen next. While they have to work within a project plan, Jennifer Russell reminds project managers how important the people engagement side is to success. But one of the biggest things to remember before lighting the fuse of your project management, is that no project is an island; interdependencies about to other projects and organizational activity.

So enjoy your Independence Day fireworks, but when you do, think about how you can engage your project organizationally and interpersonally to avoid the "dud" of project fireworks. (And apologies to Katy Perry for the post title.)

Just a Little Late

Hey! Lay off! My post is here, isn't it? Oh sure, I didn't make the 6 a.m. deadline. Big deal! Why are you being so rough on me? I'm not "technically" late.

Hmmm... sound familiar?

In project management, late tasks happen. A lot. More than most project managers care to have them happen, anyway. We work with our teams. We communicate. We build grandiose project plans. And the task is still late. And we wind up with egg on our face with our executives and our customers.

But how does a project manager prevent it from happening?

Well, the first step is figuring out WHY it happens in the first place. A few years ago, Samuel Okoro published a great blog post on project task tardiness. Some of his top reasons:

• Estimates - because our "best guesses" are padded with contingency due to the task uncertainty, we're already shooting blindfolded.
• Students' Syndrome - procrastination... enough said.
• Parkinson's Law - work expands to fill the space allotted to it.
• Integration - making sure all of the predecessor tasks are done on time so your task can start.

Sure, there are others. But these give you a pretty good idea why our projects don't get done on time. That last one is especially difficult, when you consider the compounding effect of one late task.

But how do we get the tasks to start coming in on time? The xProject blog had a few good tips:

• Schedule tasks into your calendar
• Be a time pessimist
• Prioritize
• Be honest with yourself

Those are great ideas for the project team member working on the task. What about the project manager who has oversight? A couple of my approaches are as follows:

• Schedule ahead - I avoid surprises by giving my staff a look-ahead report of tasks coming up in the next 2-4 weeks as well as the current week, so they are always looking at the present and the near-term future.
• Work weekly - Don't be a micromanager. Let your team know what's due that week and on what day. If it's on the critical path, then you can show a little more due diligence in following up; otherwise, leave them alone and trust them to do the work. If the task is completed within the week it was assigned to be done, I'm not going to ask if it completed exactly on the day it was supposed to be done.
• Public accountability - if at the end of the week, the task is incomplete and there is no good reason (or change request) to push the date back, publish the late task list (along with accountability) and share with everyone shy of CNN. I've found this to be a great motivator, as nobody wants to see his or her name associated with a late task.

Your job as a project manager is to maintain your credibility through building a culture where "late" is not acceptable... even a little late.

I'm Back

It's been a while.

I have to take a moment to thank Todd Razor and the folks at the Business Record for allowing me a few months off to address a pressing family medical situation. Now I'm able to reengage in "real life" again. I suspended much of my professional life for five months. It's time to get back into projects, writing and speaking.

Reengaging. Restarting.

We have that same challenge sometimes with our projects. Due to the economy, many projects were suspended indefinitely. Now that things are slowly improving, many project managers are being asked to restart projects. But it's not that easy as this post by Chris Vandersluis demonstrates. Issues like finding experts and contractors (both of whom have gone onto other things, redefining investment and funding issues, as well as additional oversight - both internally and externally - all combine to make the second (or third or fourth) time around harder than the first.

There are also mistakes that can be made when restarting a project. This post by PM Alliance shows six bad assumptions people make when restarting a project:

• It's a fresh start (not really - you just need to find a starting point amid all the old assumptions where everybody is on the same page)
• No research is needed (um... yeah... like the world just stopped while your project was on ice)
• We'll just fit it in with our current workload (this is an add-on to the existing workload, requiring appropriate planning and scheduling)
• Late, later, latest (a restarted project is not a late project; so don't fall into the triple constraint compression. Urgency should not take precedence over common sense)
• Bargain basement blue light special (just because it's a bad economy, don't assume contractors will bow to your desire to save a buck)
• DIY (just because budgets are tight, assuming you can do it yourself in house is dangerous).

These are just a few things that can go wrong when restarting a project. Your project may have been in neutral for a few weeks or a couple of years. Either way, it is imperative that you approach the project with fresh eyes. The goal is still successful accomplishment. Figure out what that looks like, and you'll be good to go.

It's good to be back.

Transition Time

Well, the elections are over.  We here in Iowa won't have to listen to annoying, combative campaign ads for at least another 3 days (before the caucus candidates start irritating us).

But this time frame is always interesting, as it represents the transition period from outgoing office-holders to new political offspring.  As some are winding down, others are ramping up.

Our former and newly elected governor, Terry Branstad, has launched a new site to assist with the transition, recruiting potential employees to State Government, complete with a newsletter, news room, and job bank.

Often, our project managers don't take enough time to consider transition time on projects, especially at the point the project is coming to an end and it's time to transition to a functional manager to take over... after all, somebody has to maintain the solution created by the project.

While I often mock government's approach to project management, I have to say that the Washington State DOT's site impressed me on the topic of project transition and closure.  In their words, "Begin a project with the end of the project in mind." How Covey-esque of them.

Really, the core of smooth transition is the same as the rest of the project:

• Communication - are you setting expectations appropriately for people's time, potential problems, or other issues?  Do your stakeholders know when the new solution will be plugged in?
• Visibility - now that your project is nearing the end, and the solution is evident, are you doing a good job of branding your accomplishment to keep it at the forefront of everybody's thinking?
• Accountability - are the right people and departments being held to perform as they committed?  I have to admit, the "late task report" I generate from the project plan becomes my best friend, as it provides an objective medium for accountability.

Is your project transitioning to a new regime?  Or is your project still stuck in candidate mode?

What's Tripping You Up?

Last night, I enjoyed an evening of laughter.  Carol Burnett was in town, and she held her signature Q&A at the Des Moines Civic Center.  She included many clips from her television show, and she reminisced about her costars on the show.

One such memory she shared was about Harvey Korman and Tim Conway.  The show was always performed live in front of a studio audience, and taped for rebroadcast.  Ms. Burnett described Korman as a highly talented and professional actor with an amazing range for comedy acting.  Tim Conway - also talented - loved to exploit Korman by trying to make him crack up during the audience taping.  It was his goal to "trip up" Harvey Korman.

I can appreciate that goal, at least when it comes to comedy.  A simple one-liner can do wonders for the digestion of milk and other beverages (subsequent cleaning bills notwithstanding).  However, when it comes to projects, purposeful trip-ups can be far more serious.  A side job of mine is an office politics advisor, so I've seen a few trip-ups firsthand and through consultation.  Here are some of the top trip-ups I've seen employed in the realm of project management:

1. Misinformation - word choice is powerful.  Making people believe something is one thing when it's actually something else can lead to poor requirements, missed issues, and unnecessary work.
2. Shunning - I once worked with a business analyst who could put the Amish to shame on avoidance strategies.  Leaving people out of the loop causes distrust and wastes everybody's time in the end.
3. Ignorance - "I dunno" is never an excuse.  If the question at hand is part of your accountability, then "I don't know" had better be followed up quickly with "but I'll find out."
4. Optimism - Risks are inherent to every project, so take off the blinders.  Arrogance and naivety can cause a project manager to miss potential project-saving activities.
5. Channel Wars - in communication, it is critical to select the right channel when sharing a message.  "Reply All" and "BCC" are the bane of existence for many professionals.

So what are the things that trip you up on projects?

Oh, and Ms. Burnett, if you're reading this, my one question (which I didn't get selected to ask) is this:  One of the early milestones of your career was the song, "I made a fool of myself over John Foster Dulles."  If you had to create a satirical love song for one of today's political figures (especially after the recent contentious campaign), who would it be?  (Tug, tug.)

Ready! Fire! Aim!

While researching my last book, I received a lot of handgun safety training from one of the officers with whom I worked.  Surprisingly, for somebody with little history of eye-hand coordination, I was frighteningly adept with a firearm.  (Yeah, I know... project managers and live ammo... kind of makes you want to shudder, doesn't it?)

It's an interesting and exhilarating experience to shoot a gun, and there's a lot that goes into an accurate shot.  The obvious ones are stance and aim.  There are numerous stances one can employ while shooting a gun, and it's important to choose one appropriate for you.  Aim is another critical piece.  The "sights" on your gun allow you to line up your shot quickly and accurately, but you must know how to use them, and where to focus your vision.  Still, there was a third element I wasn't aware of until I went through training:  breathing.  My instructor taught me to shoot while half-way through my exhale.  At this point, I would be most relaxed AND focused due to oxygen flow.

Now here's the tricky part:  all three of these things (stance, aim, breathing) should be in perfect alignment before you pull the trigger to get off the best shot.  In a controlled environment, you have all the time in the world to prepare yourself.  If you're in a volatile situation, you may only have a split second to get off the shot to protect yourself or a loved one.

Project management works like shooting a gun in many ways.  Sometimes, tasks can only be completed when other things are in perfect alignment.  I was recently on a project where we realized that not everything was in alignment when we proverbially pulled the trigger.  (It figures that a Microsoft product would be the bane of our existence.)  If you have a project plan in place, you at least have somewhat of a controlled environment in which to pull the trigger (we did on our project, so we had some contingency to make course corrections before we pulled the trigger a second time to hit our bullseye).

The Expert Program Management blog had a useful post on dependency mapping, which is a great Gantt-Chart based visual tool to see where things have to come together.  Denis, the author, states that there are some key benefits to using this tool:

1. It allows you to ensure the complex network of project interdependencies is coordinated and synchronised.
2. It allows you to track that work packages produced by the different project teams are integrated.

Often, knowing what tasks come before or after other tasks is intuitively obvious and easy; other times, not so much.  Spending time having these discussions during the planning phase, thereby mentally stepping through your project before executing it, is a benefit beyond words.  Not doing so sets you up to "Ready! Fire! Aim!"  (Not a good sequence.)

So the next time you need to pull the trigger on starting your project tasks, ask yourself if you've thought through all of the components needed to make it a successful shot.

Carpe Factum!

A Little Landscaping Project

My project management skills around home are likened to the story of the cobbler's children having no shoes.  I can manage highly complex, multi-billion dollar initiatives for my clients; it's just that when I'm at home, I don't want to think about things like dependencies or resources or estimates. (I'm still forced to do so, but it's under duress.)

Such is the case with our recent landscaping project.  I started building a retaining wall soon after we moved into our house almost 15 years ago.  Note the use of the word "started."  Also, note the lack of the word "finished."  Being so busy managing others' projects, I ended up ignoring my own far too long.  I decided it was time to outsource the project to a true landscaper, in order for us to put this one in the "done" column.

I collected bids and selected a landscaper with a proven track record and a good understanding of what I wanted and needed, who could complete the project within budget and within a reasonable time frame.  Before any of that could happen, I had to define what I wanted, and I had to let all of the bidding contractors look at what was there now.

As many of your know, I'm a HUGE big ol' geeky fan of systems thinking.  What I had to do before any of the work could begin, or before any of the estimates could be written, was define the OUTPUTS of the system.  If you are a business analyst, you call this requirements.  All of the contractors found out I wanted a two-tier retaining wall on the south side of my walk-out patio, and a three-tier retaining wall on the north side.  I had to specify the height of the wall.  I had to let them know what kind of bricks I wanted.  In other words, my ideas (OUTPUTS) became their INPUTS to their estimates.  It also became the criteria for the FEEDBACK LOOP to determine whether the project was correctly completed.

Project management is filled with systems thinking.  J. Alex Sherrer wrote an amazingly informative and comprehensive piece a few months ago on the use of systems thinking in projects.  He drives home the point of relationships between systems quite well:

And systems don't just interact with themselves; they're part of ever larger and more complex systems. Because of these internal and external relationships and influences, a system is complicated; take away any part of a system, its behaviour is altered; rearrange the relationships within a system and it'll function differently; make a change to a component within a system and that change could reverberate with unintended consequences to other systems.

When you become a project manager, post this paragraph on your wall.  EVERYTHING you do is related to somebody else.  You will receive information from others, which will prompt you to make decisions.  You will create things which others' use as inputs to their systems.

I just led a workshop on this very thing at the LavaCon conference in San Diego.  At the end of my workshop, I gave the participants the paragraphs from the website's main page, articulating the business reason for attending the conference, and asked them to map it into the systems model.  They soon found it wasn't as easy as it looked, until we stepped back and agreed on our system's output.  Then all of the pieces fell into place.

My landscaping project turned out amazingly well thanks to BW Construction in Urbandale. Bob Wolfe, the contractor, took my thoughts, and from it he was able to create his own outputs in the form of successful project completion.

What input-output relationships exist on your project?  How can you manage them?  What can you do to ensure you are successful at communicating those relationships?

An Offer You Can't Reuse

I admit it: I have a strange relationship with most IT (information technology) departments. Yes, I started out as a COBOL programmer many years ago, so I understand the mindset. Still, the more I get involved with IT staffs on projects, and especially CIOs (chief information officers), the more I'm left scratching my head.

Let me ask my readers this: who drives the projects within your organization? Is it IT and the CIO, or is it the business side of the house (those departments whose activities generate revenue)?

Often, I see IT departments run like an organized crime family, calling the shots on what gets done and what doesn't. However, what is the business VALUE they provide in the projects they choose to pursue? Often, when requirements are driven by the IT department, you run into a lot more fluff in your projects than necessary. As the MicroFocus blog indicated recently:

Industry analysts estimate that around 80% of all software rewrite costs can be avoided at the requirements stage*, and that the majority of eventual project failures are caused by poor requirements practises. Another major cause for concern is the number of rarely- or never-used features in new software applications – according to some studies, as much as 45% of newly developed features are never used**. Eliminating these problems is therefore a key priority for CIOs operating in straitened economic conditions and having to focus on maximising value from every dollar they spend.

This means that when figuring out the scope of the project, if the requirements are left unchecked, about half of what is implemented is useless. This begs the question of why business departments allow IT to get away with dictating what projects get attention in the organization.

I think the answer lies in a post Oliver Mallassi published a couple of weeks ago. In sharing his own software project horror story, he hints at one of the major misconceptions which many IT departments perpetuate: FEAR.

"Do it our way and nobody gets hurt."

"We're the only ones who really understand how things work."

"Don't you trust us?"

Mallassi quotes one of my favorite authors, Tom DeMarco, in diagnosing the fear. Do people get to say what's on their mind? Are decisions based on power plays rather than common sense? Does the CIO make you kiss his pinky ring when you walk into his office?  (Okay, I threw that last one in myself.)

If business does not start challenging IT departments, they may find themselves with numerous projects which are behind, are over budget, and are laden with features which will never add value to the bottom line.  IT is a service provider and a partner, NOT a driver.

Failing Communication

OK, let's get a few things straight.  I've been teaching at Drake for over 10 years.  I love the school.  I earned my MBA there.  My wife earned both of her degrees there.  I have some amazing colleagues in the College of Business and Public Administration.  My students have been fun, challenging, outstanding up-and-coming professionals.  Even stepping onto campus energizes me.  I believe in the school, its mission, and its existence.  While the rest of you Iowa and Iowa State fans hold your silly rivalry, I laugh in all your faces.  I bleed Bulldog Blue.

So the whole D+ ad campaign bothers me.  Not just bothers me... it irritates me to my core.  I loathe it with the same loathing that my project management students feel toward my multiple choice final.  Yes, the campaign is effective.  Inquiries are up.  Student visits are up.  It's getting attention.  And as most marketing types would attest:  ALL attention is good attention, right?  Well, not if you believe what the mainstream media is saying.  The internet was littered with stories this week.

The marketing spokespeople sent out an email message yesterday to faculty and staff defending the campaign and sharing all of the positive statistics.  The message is clearly reaching prospective students.  But existing students, faculty, and alumni are NOT happy.

But this post isn't really about bashing my alma mater/employer.  This, too, shall pass.  No, what I want to point out with this marketing fiasco is what can happen on your PROJECTS if you don't think through your communication plans.  At the beginning of every project (and when I say "beginning" I mean when your project is still just somebody's idealistic brain-fart), the project manager needs to start creating a project communication plan.  You need to think about every audience:  business partners, software users, suppliers, customers (internal and external), IT support, industry watcher, and (sigh) marketing.  Then build a communication plan around the messages, frequency, and channel/medium each member of your audience needs.  Finally, weigh your communication plan against those stakeholders who will see it, but for whom the message is NOT intended.  That last one may send you back to the drawing board, but it will be worth it.  The conventional wisdom in project management circles is that a project manager's time will be spent communicating... between 70-90% of the time.

So to prevent a project failure (or at least a D+), make sure you are communicating effectively with ALL of your stakeholders... not just the ones to whom you THINK you're communicating.

Carpe Factum!

Gateway to a Project

We just returned from a vacation in St. Louis.  Because my older daughter has been reading the Percy Jackson series, she wanted to see where a pivotal scene occurred in the first book... atop the Gateway Arch.  When I was a kid, it was a great novelty to just go up to the top of this cool-looking thing.  Now, as an an adult, I was more fascinated with the history of it.

The monument was first conceived in the mid-1930's.  Attorney Luther Ely Smith wanted to restore the St. Louis riverfront from decay, so he began pushing for a monument honoring Jefferson's 1803 Louisiana Purchase and St. Louis' role as the gateway to westward expansion.  President Franklin D. Roosevelt supported the idea.  Many meetings and bond issues were held to gain support for the idea.  It wasn't until 1947-48 that a national contest was held to select a winning design for this monument.  Architect Eero Saarinen's design of a catenary curve was selected.  Construction did not begin until 1963 and ended in 1965; however, the tram which transports people to the top was not operable until 1967.  The Arch opened to the public in 1968.

Granted, this is just a thumb-nail sketch of a very rich history of the entire project; however, there are some powerful project lessons to be learned:

• Project definition can sometimes take long periods of time, and it is important to define the problem well and figure out who is going to take ownership of the problem (i.e., pay for it) before moving onto the solution phase.
• The longer amount of time spent on planning, the shorter amount of time proportionally will be spent on execution (note the length of time between awarding the winning design and actual construction).
• Know what issues are show stoppers and which features are "add-ons" - structural problems caused the Arch construction to halt; items like the tram were handled after the external portion of the Arch was constructed.

And thus ends the Johnson summer vacation for 2010.  Someday my children will be thankful that their dad geeks out on project management education... even at the Gateway Arch...well, ok... maybe not.

Carpe Factum!

Sweat the Small Stuff

I've always appreciated Stephen Covey's example he shares about the big rocks and the small rocks and the sand.  If you have a hefty collection of each and are asked to fill up an aquarium with all of them, unless you start with the big rocks first, then move to the small rocks, and finally fill in with sand, you will not fit everything into the aquarium effectively. 

Then it will be the big rocks (the most important tasks in your life) that will suffer. Brilliant analogy.

In project management, we often remember the big rocks: the tasks on our project plan, the status report, the issues log, team meetings, the deliverables. Those are the only things that make or break a project, correct?

Well, yes and no. Often, the things I see derail project managers are the small rocks like allotting time for WRITING the status report, TRACKING the issues log, HOLDING the meetings, and OBTAINING SIGN-OFF on the deliverables. Each of these seemingly small tasks pale in comparison to sitting down a group of business analysts and programmers to create something big and brilliant. While none of these "small rocks" in and of themselves get you to your final project completion, ignoring them can prevent you from reaching your goal.

Maintaining these small rocks is also a matter of project maturity. The Software Contract Management blog recently shared a piece on scope management and the capability maturing model. Tucked away in one small corner of the article was a critical piece of advice: "Please keep in mind that your responsibility extends to all work on the project, including administrative work, not only the construction" of the software system.

As a project manager, allow time on your plan (10 percent to 25 percent is my general rule) for these "small rock" activities. Ignoring them as inconsequential may prevent you from effectively addressing your "big rocks."

Carpe Factum!

"Kind of" Immediately

I couldn't believe my ears.  I was on a phone call with the project stakeholders who were driving the requirements of our project. They were the only ones who could answer our questions and resolve our issues, and also the ones who were forcing the project in the first place to make us compliant with their regulations.

And when asked when they would get us a response on a critical issue, the barely-out-of-project-puberty spokesman on the other end of the conference phone squeaked, "Uh... we'll get on that kind of immediately."  (For the record, emphasis here ended up being more on the "kind of" and less on the "immediately.")

(NOTE: my wife loved it when I took up blogging, as it has become a form of therapy for the occasional silliness of project management.)

Let's take a step back here and look at date commitments. Simply put, when asked for a specific milestone date, here are some of the responses to avoid:

• "I'll work on that as soon as possible."
• "I'll get at it when I can."
• "It's in my inbox." (Not even a real response here.)
• "Who are you, and what do you want?"  (Trust me, it's happened.)

Instead, attempt to focus your stakeholders to give clear, unambiguous answers which involve dates:

• "That will be started on Aug. 2 and will last two weeks."
• "We will finish no later than Oct. 1."
• "If no assumptions are violated, we expect a finish date the last working day of this month."
• "We will release new versions of the software every other Wednesday between now and year end."
• "That has to coincide with the quarterly sales meeting scheduled for Nov. 15."

Sometimes a date isn't possible because of other tasks or activities going on.  That's alright as long as those dependencies are clearly stated:

• "We cannot start the requirements until Project Zebra's testing is complete." (Followed up by asking when that date is, so you can talk to Project Zebra's team.)
• "This task has to coincide with the completion of unit testing." (Again, ask for dates, but you at least know what the dependency is.)

In the case of clear dates or dependencies, all should be tracked and communicated via project plans, communication plans, and/or issues logs.

And at no point in the management of your projects is the phrase "kind of immediately" ever acceptable.

Oh Say, Can You See?

This Independence Day holiday has been an unfortunate weekend of fender-benders for our household.  On Friday, a minivan pulled out in front of my wife.  Yesterday, while driving the rental resulting from my wife's accident, I was rear-ended by an impatient teenager.  In both cases, the drivers appeared to be impatient, and both made bad decisions based on faulty assumptions.

This sometimes happens in project management as well.  I once worked with a consulting executive who practiced "hit-and-run" project management, as he would not bother with the details (even if they were shared with him), would make assumptions based on his reality of the project, get blindsided by his own bad assumptions, and then proceed to blame others.

Project management is primarily about communication, but occasionally assumptions must be made.  Assumptions cannot be made by sitting in one's cubicle or going out having long lunches or numerous off-site meetings.

Scott Johnson from the @task blog wrote a fascinating piece about the freshness of conversation in project management.  He said that data

"are good in that if they were accurate, you could make great decisions. They are not good in that people don't trust them. By the way, we have seen this same behavior with project management systems too. People have a lot of data; green yellow and red dots; projections, plans, variances, costs, potential revenues, efficiency metrics, trends, & etc. When it comes to executive review, one piece of data seems to decide whether a project or sales opportunity, a project manager, or a sales manager gets additional executive attention - that piece of data is the conversational status and it's freshness." 

Well said, Scott!.  If a project manager really has no clue what is going on, then no amount of statistical data can save his or her tail.  They need to be walking around, talking to team mates, listening to (and documenting issues), and generally communicating.  On one client,  I juggled three major initiatives.  The CIO asked me how I was able to do it, and I honestly told him I had amazing teams on all three, relied on them, and communicated with them.  I'm not a superman PM, and quite honestly, multi-tasking has never been a strong suit.  But I was really been lucky to have great teams who understood the power of conversation, of communication, and observation to get things done.

But maybe you're the type of project manager who enjoys seeing fireworks in an office setting on a regular basis.  If that's the case, sit in your cubicle, keep your head down, talk to nobody, and keep quiet.  You'll eventually have more fireworks than you can imagine.

On behalf of my fellow contributors, Happy Independence Day from all of us here at Iowabiz!

From Point A to Point B

 We're here. We need to get there. But how?

(Well, that's project management summed up in under 10 words. But I'm sure you probably want a little more than that, right?)

I found a great post by friend and colleague, Josh Nankivel on the powers of using mind mapping as a project management tool.

In short, a mind map is an amazingly effective brainstorming tool which allows you to keep your thoughts organized in a series of hubs and spokes as you continue to build out.  It's not as linear as "traditional brainstorming" and quite frankly, that's a good thing.

This weekend, I will be leading a workshop with a group of high schoolers attending an entrepreneur camp.  I'm the "kick off" speaker, and I get to shape their tender little minds for 3 whole hours, talking about the importance of creativity.  I'm going to approach this workshop with all of the energy and ADD that this "old guy" (which, in the eyes of the average high schooler, I am) can muster.  One of the tools they will learn is mind mapping.

After reading Josh's post and watching the video, you may be curious where this tool (and creativity in general) have a role in project management.  The answer?  ALL OVER THE PLACE (i.e., from initiation through closure).  Let's review some ways this tool may come in handy:

• Initiation: problem development and solution generation
• Planning: identifying tasks and brainstorming for possible risks
• Execution: issue tracking and resolution
• Closure: lessons learned

If you're in project management, creativity is a survival skill.  You will be called upon to be creative at the drop of a hat. If you are not naturally creative, you'd better surround yourself with people who are... and you'd better develop the skill yourself.

While project plans and schedules tend to be somewhat linear, the projects themselves rarely are.

Carpe Factum!

Project Management Nuggets

I've been fielding a few questions recently about really good resources for project management material. So for this post, I thought a "mash-up" of some of my favorite spots would be worthwhile:

Books:  You'd be hard-pressed to find anything more comprehensive than the Project Management Bookstore online.  It's a subsidiary of RMC Consulting, but if they don't carry the book, then it's not worth knowing about within the project realm.  They periodically do author webinars (free) and provide other great resources for project managers.

Certification:  I earned my certification back in the mid 90's before all of the great resources were available.  From those I've talked with who've earned their certification (PMP) in the past decade, RMC Project Management provides the most comprehensive reviews available.

Blogs:  Wow, this one is tough.  But there are a few blogs that provide consistently excellent writings on project management, and have for some time.  Among them, Raven's Brain (it's been a while since she's blogged, but even her old stuff rocks), Glen Alleman's Herding Cats, Kevin Brady, and Scott Berkun all provide pithy yet insightful ponderings on making your projects run more effectively.

General Sites:  Top of the list are Gantthead.com and ModernAnalyst.com.  Gantthead will appeal to the straight PM's among us, while Modern Analyst is geared toward the highly valued yet underappreciated Business Analysts.  Looking for soft skills?  The best bet in a project environment is OfficePolitics.com.

I hope these resources will serve you as well as they've served me.

Carpe Factum! 

You Can Teach a New Dog Old Tricks

It was refreshing to watch Betty White host Saturday Night Live a couple of weeks ago.  It's been a while since I watched the show just because the writing has been a bit sluggish, and the current set of actors don't seem to keep pace very well.

With Betty White came a host of former SNL stars to save the day (and give her a comedic backdrop) for her brilliance.  The really great thing about it all was her age and experience served as an asset to the show.  One could tell both the writing and acting stepped up a notch for this grande dame of the small screen.

In your projects, are you tapping the experience of the ages?  It's interesting to talk to the "old guard" of project management vs. some of the newer PMs.  No, we don't sit around with our walkers commenting about how the PMP exam took all day to complete back in the day (well... it did) or how they drew their Gantt charts by hand (they did, too).

But experience in project management teaches you the same things any seasoned comedian knows:  rhythm and timing.  We learn when to be quiet until the opportune time for a punchline.  We know our blocking, where to stand front and center on stage and when to support somebody else in the limelight.  We know how to play off of the strengths of others to make the whole team look better.

There are a lot of really great project management blogs out there.  Heather Buckley was kind enough to consolidate quite a few of them that I visit... and these are some brilliant bloggers AND project managers.  Check out her post and her links.  There are some really amazing "old dogs" who know all the "old tricks" to project success.

So if you're a project management neophyte, before you try to wow everybody with your freshly minted PMP and your vast knowledge of all of MS Project's tools, stop and take a deep breath.  Check out some of the old dogs who have done it really well for years and years before you were even in the work place.  They may be able to teach you a trick or two on stepping up your game before you step on anyone's toes.

Live from Des Moines... it's Wednesday Morning!  (Ya know... it just doesn't have the same kick.)

Carpe Factum!

Soft Serve

What can I say?  I love Snookie's Malt Shop.  Oh sure, there are plenty of great ice cream shops around Des Moines, but there's just something about the atmosphere at Snookie's that makes it special.  And they do whip up one heck of a great soft-serve ice cream.

There's another kind of soft serve which is really great... it's your people skills.  I'm in the middle of teaching a two-day class for the University of Wisconsin-Milwaukee on Business Analysis.  It is an overview class, so we're covering a lot of material.  When I was developing the curriculum, I asked all of my business analyst friends what their top priorities would be for such a class.  The answer was almost consistently "soft skills."  In project management, we do a lot with plans and schedules and budgets and scope documents; however, knowing how to do all of those will not mean anything if you can't communicate and influence people.  Understanding how to manage office politics, how to be creative at the drop of a hat, how to handle conflict better, and how to sell your ideas effectively.

I know some project managers who are masters of the technicalities of our trade, but who are dismal failures at the practice of project management.  Why?  They've never put an emphasis on the "soft serve" of the job.  As you are working to become a better project manager, please don't neglect the critical skills you really need to know.  And if you happen to be in Beaverdale during the spring and summer months, have some REAL soft serve.

Carpe Factum! 

In Hot Water

Todd Razor, our intrepid editor here at IowaBiz, knows that I push the envelope for completing my articles on time.  But he also knows my track record for doing so, and he no longer panics with e-mails or phone calls the evening before a post is due.

This is one time we may have had an exception to that rule.

At 9:35 p.m., I sat down to write my post on project management for Iowabiz.  I was thinking something nice and green in honor of Earth Day 2010.  Oops... need to check on something in the basement.  Hey, what's this wet spot?  And this one?  And this one?  We've NEVER had water in our basement.  I called my wife down.  She went into bloodhound mode (she's really good that that) and was able to isolate the growing puddle to our hot water heater.  Our 14-year-old-now-rusted-out-on-the-bottom water heater.

We were in hot water.  Literally.

We scrambled to pick up some of the critical items, which generally don't play nice with a growing circle of wetness (stacks of my books, for one), and got things to higher ground.  We called our neighbor, a handyman-extraordinaire, who was able to give us some good names of plumbers. He said he would get right on it first thing in the morning (so I hope by the time you read this, there is a plumber at my house).  We also shut off the water and the gas to the current hot water heater.

So... that brings me back to my IowaBiz article.  And I'm wondering how YOU handle the crisis-laden curve balls which come out of nowhere and land smack-dab in the middle of your nicely laid-out schedule. John Lawlor wrote a great post summarizing Business Continuity Planning for the organization, and many of his elements apply to projects.  There are a few add-ons I'd like to make to keep you out of hot water:

1. Maintain your project - make sure the infrastructure of your project is sound, that you are tracking issues and status regularly, that you are doing a pulse check, and that you make sure there's no "rust" or "leaks" showing.
2. Alert early - a small part of me wanted to ignore the water when I first saw it.  My wife and I were both busy.  One of the kids must have just spilled something.  But there was enough evidence of something wrong, I had to let my key stakeholder know what was up.
3. Diagnose the right problem and cause(s) - our first thought was that we had water seeping up from the ground.  But that didn't make sense, given the fact that we'd never had that problem prior.  We wondered about possible leaks from upstairs.  It was only after we pulled back the carpeting, saw the water (and its directional movement) that we were able to figure out the source of the problem.  Be prepared to do some detective work and don't jump to conclusions.
4. Know your go-to people - I called my neighbor once we knew what was going on.  He deals with this kind of thing all the time, so he told us what to do and how to do it.  Then he promised to have his contact call us first thing in the morning.  Know who your project go-to people are, and treat them with the respect they deserve for covering your tail.
5. Solve it quickly - I'll be heading to the hardware store in the morning to buy a new hot water heater, and doing what it takes to get it installed quickly and correctly.  When one lives in a house with three females, lack of hot water is an emergency not to be taken lightly.  On your projects, when the solution is evident, don't mess around.  SOLVE IT.  It may mean unpleasant things like firing people, but this is where the "Carpe Factum" mindset comes in handy.

So now it's after midnight and I'm just NOW finishing my post.  I'm still on time for that, despite the huge set-back in my otherwise perfectly-planned evening.

At least my mishap provided some needed last-minute inspiration.

Carpe Factum!

Resurrecting Your Project

Happy Easter from Iowabiz.  As those who have been reading my posts for a while know, EVERYTHING is fair game for a topic.  No, I'm not a project manager with a messiah complex; however, let's talk for a minute about resurrecting your seemingly dead projects.  You know which ones I'm talking about... those that hold the secret of salvation for your organization, yet - for one reason or another - have been betrayed and crucified by the current establishment.  (NOTE:  All religious references contained in this post do not necessarily reflect those of Iowabiz or the Business Record.)

I've shared on my blog and in my first book the SPARTA method for project rescue and recovery.  While the acronym is easy, the steps can be painful and difficult, depending on both the project and the organizational culture.  Still, as a review, here they are:

• Stop - quit executing under the old rules and allow the project to get back on its feet
• Parameters - set boundaries for what the new project must accomplish (and what it needs to ignore)
• Assumptions - document what conditions need to exist (or what risks need to be considered) for project success
• Roles - be very clear about who is doing what
• Tasks - create a new project plan with recovery and the end goal in mind.  Make it quick and effective.
• Accountability - hold some feet to the fire. There's a reason the old plan (if there was one) failed. Make sure there is follow-through

OK, that being said, there are a couple of things from THE resurrection story which are applicable for project recoveries.

First off, make sure you know what success looks like and don't be so surprised when it occurs.  My favorite part of the Easter story is not at the empty tomb, but on the Road to Emmaus (Luke 24).  Jesus' followers had Him in their presence and they didn't even know it.  He dropped all kinds of clues that He had been successful in His master plan, but still they were too dense to figure it out until He spelled it out for them.  Some times project teams and stakeholders can have success staring them in the face, but unless those in leadership spell out that success (however painful it appears at the time) is occurring, people often don't get it.

Second, there will be detractors who do not want you to be successful on this project.  Certainly, the government had a stake in making sure Jesus' resurrection wasn't broadcast (Matthew 28).  Sometimes stories circulate about any little problem on the project's recovery, just as they did in first-century Roman-controlled Jerusalem.  Make sure the facts speak for themselves about the project.  If you are maintaining good records about progress, and you keep everything factual on your project plan, status reports, and issues log, you will have credibility on your side.

Finally, keep the main thing the main thing on your resurrection.  No need to share the stage with fictional rabbits bearing candy.  If your project is important enough to warrant a recovery effort, then it is important enough to give the right level of executive attention and resources and focus.

Enjoy your day, however you celebrate it.

Project Snowjob

In the mere two weeks since my last post, all of the snow has quickly - almost miraculously - melted and evaporated.  Wow, go figure.  Of course, on my back patio, all of that snow was masking an entire winter's worth of doggy bathroom (we can guess which syllable of ShihTzu gets the emphasis).  So once the snow was all gone, I was left with an unpleasant mess to clean up.

Ick.

I've been thinking a lot about project rigor these days (some might call it bureaucracy).  You know what project rigor is.  It's writing status reports, holding meetings, tracking issues, writing a good business case, following procedures, maintaining a methodology, etc., etc., etc., etc. ad infinitum.  Certainly, the larger your project, the more safeguards need to be put in place to govern both people and tasks to ensure a successful delivery.  Is it possible, however, to take the amount of rigor too far?  (Psssst, the answer is yes.)  And that also leads to another question, why are you adding on more rigor than you need to manage the project?  Are daily status reports really needed?  Must you build an organizational chart on every project?  Is it that you think you are helping the project by adding more rigor?  Or are you simply piling on more snow to hide what is lurking underneath?

David Christianson, of the Dark Side of Technology blog, wrote an amazing piece a couple of years ago about project rigor.  The question isn't about whether you have too much project rigor; it's about whether you have the right emphasis on those things to which you must adhere.  As David bullets it out quite nicely, he shares where your focus as a PM should be:

• Telling the truth about my projects.
• Eliminating ALL activities that don’t contribute to the delivery of valuable working software.
• Creating achievable commitments to deliver.
• Managing focus of a project team.
• Understanding and fulfilling the needs of the business.
• Creating an environment that optimizes the ability of project team members to contribute.

This kind of project rigor is build on transparency and accomplishment, rather than hiding the layers of doo-doo under the snow of inactivity.  The one who ends with the most status reports and the biggest issues log does not necessarily win.  He just spent a lot more time on things that don't add value.

As you clean up the mess from under the snow, just remember who put it there in the first place.  Snow can only cover "crap" for so long before you see it and have to deal with it for what it really is.

I Dunno

I'm on a new project now. Well, actually the project isn't new... I'm just the new kid on the block.

So far so good.  I haven't dropped a ball, and my project leads and sponsor are all still talking to me, and everybody smiles when they see me coming (and not one of those oh-crud-here-he-comes-I'd-better-paste-a-smile-on smiles either... so there).

We're in the planning phase of the project, which is normally a good thing... except...

Many of our requirements are being driven externally.  Whenever this occurs (in ANY organization or ANY industry or ANY project), you run the risk of some information not being available when you need it.  Such is the case here.  There are some things we just don't know.  It makes it hard to estimate tasks when you don't know what you're doing.

With some project managers, that can grind things to a halt.  I'm lucky enough to have a pretty smart team who can connect the dots and make some educated guesses.  We've had some discussions about not knowing all the specifics, yet being able to estimate for requirements and scope that do not yet exist.

It's not quite so daunting as it may sound.  Martin Harris of Transient Technology wrote a great piece last month about estimates.  As he says, they are not the same as commitments.  Figuring them out is as "simple" as comparing against other similar experiences.  This is exactly what I've done with my team.  I asked them what they'd accomplished.  Then we talked through how to use this experience as a baseline.  As Harris pointed out in his article, there is a bit of a poker metaphor to this technique.  Figuring out what size or complexity "beats your hand" is important in making logical estimates.

Example:

Task 1 took four days and 10 effort hours to complete.  The only thing you know about Task 2 at this point (pending receiving your scope requirements) is that it is probably twice as complex as Task 1.  Hence, the logical thing to do is give it eight days and 20 effort hours.  However, you also know you are time-boxed and only have a week to complete it; therefore, the duration shrinks to five days while the effort hours stay constant.  But because you know the requirements are uncertain, and there may be some office politics involved in finalizing them, you may want to bump it up to 30 effort hours due to additional meetings and phone calls.

Granted, that's a very simplified example, but the reality is the creation of estimates is simply narrating the path from the known into the unknown.  The other thing I've been telling my team about estimates is they are learning opportunities.  I don't use missed estimates for witch hunts; I use them for learning opportunities.  The caveat for this is to ask them to document any known assumptions used for building their estimates.

So "I Dunno" is an acceptable answer for requirements.  That lack of knowledge should not be a road block to creating estimates.

Carpe Factum!

Trade Ya!

Image via Wikipedia

Last week, I had the pleasure of having lunch with my fourth-grade daughter.  While it was fun spending time with her, it was in many ways a surreal view of a sort of stock exchange floor, where food items were traded and bartered back and forth.  I lost count of how many times I heard the phrase "trade ya" from the children around me.  Trading, it seems, is a skill we learn early in life... and unfortunately forget when we hit adulthood and projects.

I started a new project this week, and it's a new client, so I'm drinking from the proverbial fire hose of information.  I'm learning about their products and services, about their company culture and about my project.  Even though it is the honeymoon phase, I'm still anticipating great things:  from them, from the project and from myself.

As with every single project, I'm having discussions about the triple constraint.  What is that, you ask?  Fair question... as it has been a long time since I covered it here.  The triple constraint is a core concept of project managers.  Some people describe it as good-fast-cheap-choose-two.  I prefer not to use that, as I think it oversimplifies the concept.

Essentially, think of a project in terms of a triangle.  On one side, you have schedule.  This is the number of calendar days (weeks and months) you have to complete the project.  On side number two, we have resources, which is anything that costs you money.  It includes supplies, software, people (and, no, they're not "free" just because they're employees), knowledge, expertise, et cetera.  The final leg of our triangle is performance, which is a interdependent combination of scope (how much are you going to do) and quality (how well are you going to do it).

Because of the relationship of these three triangle sides, you can't change one side without changing at least one other side.  Here's where the tricky part comes in:  Changes will try to occur, but will you as a project manager let them control you, or will you control them?  I liked how this was worded on the Project Daily blog recently:

If the client decides to change or add to the features list, it's up to the PM to make it clear to all the stakeholders that other things may either have to change or suffer. A lot depends on the initial agreement, the change control process, the relationship with the client, and how much wiggle room was included in the original estimates, but in any project based work, a shift in one piece will likely cause a shift throughout. By letting the client know right away that their request might effect the delivery date, the cost, or the quality, you put any trade-off decisions squarely into their hands, with known consequences.

My discussions this week with my project stakeholders have been simple.  Which constraint can move the least?  Which constraint can move the most?  (There is no one right answer to this question, but there is one big wrong answer:  "None of them can move.")  If you can get your decision-makers to agree on this one concept, you will be light years ahead of many other project managers.

Law of a Traction

It's winter in Iowa. (Please, keep the cheers to a dull roar.)

We've had a whopping ton of snow. We've had arctic blasts. We've had wind-blown drifts. And we've had ice.

It sort of turns walking and driving into a) a new Olympic event; or b) entertainment (provided you're not the one on the ice).

Sometimes it's hard to gain traction on the slick surfaces, no matter how much testosterone your SUV is channeling.

Are your projects maintaining their traction as well? There are a few articles about project starts and stops.

According to the Standish Group, starting and stopping a project multiple times is one of the factors which leads to failure. In RUP, stops and starts go hand-in-hand with multiple bug fixes. The Theory of Constraints blog links multi-tasking as a cause of project starts and stops. Gav Thorpe relates this phenomenon to the project of writing a book (boy, do I understand that one!).

But how does one get (and keep) project traction on the slippery, wintry surfaces of organizations?

1. Leadership - the executives writing the checks need to ensure the resources stay dedicated and focused to the project at hand
2. Prioritization - have criteria in place to determine when or if a project should be shelved and what constitutes "more important work"
3. Communication - ensure all stakeholders know when and why a project or task has been stopped and why... and when/if it will be restarted
4. Opportunity Cost - understand what the stops and starts are costing the organization in terms of ramping up, learning curves, politics, et cetera

If you can keep your projects moving over the ice of competing demands, then you should maintain your traction through completion.

Carpe Factum!

Romancing The Clone

Last Saturday, I was invited to address a local group of romance writers to talk about accomplishment.

What's that, you say?  What would I have to offer a group like that?

Fair question.  After all, Gantt charts do not have heaving bosoms.  Status reports do not sweep people up with their rippling biceps.  Project sponsors do not sulk and pout (er... um... wait a second... let me get back to you on that one).

But throughout our round-table discussion, we were able to focus on what we had in common as writers.  Since all of my books are business fiction with characters and a plot line, we were able to discuss the development of our books.  We shared issues on writers block and finding inspiration.  We pondered the "joys" of marketing our work.

Project managers often times isolate and silo themselves.  Because, by definition, every project is unique, they buy into the fallacy that no other project manager could possibly relate to what they are going through.  After all, what could a project manager in life annuities possibly share with a construction PM?  Is it even possible for a medical project manager to talk with a marketing project manager?

The reality is that most projects have (or should have) things in common.  A favored older post by Glen Alleman articulates this better than just about any blog post before or since:

Certainly the development of a building, highway, and sewage system is not done in the same way the development of a software system - at least at the detail level. But David and Jim [two of Glen's peers] seem to be missing the field observation of the massively parallel activities, customer interaction, continuously changing plans and deliverables focus that takes place in construction projects.

The reality is that every project should possess the certain common elements, which I detailed in my last blog post on this site, when I talked about auditing a project.

My point?  After two decades of working in this town, I've noticed that project managers like to (for lack of a better term) in-breed.  They network with the same people from their company.  If they do network outside their organization, they seek out project managers in their same industry.  While it is not universally true, alarmingly many project managers do not seek those "outside their village."

If you are new to a project, I would encourage you to seek out project managers from other companies, industries, and viewpoints.  While no one project is a clone of another, there are still plenty of lessons to be learned from those who are NOT like you.  You never know what you might learn from a romance author.

Carpe Factum!

Open Wide!

As you read this post, chances are high that I am sitting in a dentist's chair with my mouth wide open while various people prod around my mouth to ensure I've been behaving myself with respect to dental care.  When I brush and floss, I am generally constrained to what I can see and feel myself.  My dentist and hygienist have all kinds of picks and mirrors and other pokey, proddy devices to ensure that everything that should not be in my mouth has been removed.

One of the services I provide as a consultant is a project audit.  This is where I make my clients "open wide" and poke and prod around their plans and status reports and issues logs to ensure they are taking good care of their projects.

The Thinking Made Easy blog justifies why a project audit is a critical element of project management:

Projects rarely run through their full life without some surprises. It is hard for the customer or project sponsor to work out which situation they are in before it's too late to fix the problems economically. That is where a project audit comes in: an independent assessment of some or all aspects of the project's health buys at the least peace of mind, and in other cases can make the difference between problems nipped in the bud and a project whose timescales and costs are out of control.

So what goes into a project audit?  Since I am generally called in sometime in the middle of project execution, I will ask for five specific deliverables:

• Business Case - what was used to justify the project?
• Requirements - how was the project solution communicated?
• Project Plan - how were the requirements translated into tasks and resources and timelines?
• Risks and Issues - how did the project manager communicate what wasn't going well?
• Status Reports - how did the project team communicate progress against the plan?

As far as how a project audit is completed, look at this excellent post by Michael Stanleigh, where he details the three main phases of an audit:

1. Success Criteria, Questionnaire, and Audit Interview Development.
2. In-depth Research.
3. Report Development.

Remember, in the end, the goal is not to shoot messengers or drown witches; it is to get the project back on track or figure out if the project should be scrapped.  I've only had one hygienist who scolded me about my exam checkup.  She then had the audacity to defensively tell me that "some people" like teeth cleanings.  I responded that "some people" also like White Castle Hamburgers and vacations in Branson and asked what her point was.  Suffice it to say, she is no longer my hygienist.

So every once in a while, stick your project in a chair, shine a light in its eyes, and make it open wide.  You never know what you might find.

Carpe Factum!

Just Like Lights on the Christmas Tree...

At the Johnson household, we like our Christmas traditions.  Put up the tree Thanksgiving weekend (at least once the turkey and stuffing have settled and we can bend over again).  Caroling sometime in December (preferably on key).  Children's program at church (cute factor).  Listen to Karen Carpenter and The Blenders at least 347 times.  Pizza on Christmas Eve (and NO mushrooms... fungus - ICK).  Open presents Christmas morning (because, let's face it, those people who tell their kids Santa comes on Christmas Eve are just plain wrong).  Oh, and the big one... let my wife put up the Christmas lights on the tree.

You see, she's very meticulous about lights on the tree.  I've tried doing it a couple of years, and it's never up to her very high standards of how a Christmas tree SHOULD look:  always start at the bottom and move up, and clear lights embedded so that no cubic inch is without some kind of light source.  OK, so that might be an exaggeration, but I've learned after 17 Christmas seasons together to just stay out of her way when it's time to put lights on the tree.  (There will be plenty of time for me to hang my collection of Harley-Davidson Hallmark ornaments later.)

But she has a great project manager mindset when it comes to installing lights:  bottom-up and transparency.  Start at the bottom and keep it all visible.  How does this relate to project management?  Recently, my good friend Kevin Brady, across the pond in UK-based Clarety Consulting, held a conference call with my Drake project management students so they could grill him on his vast project experience in multiple countries and large scale initiatives.  Kevin blogged about it on his site recently, and his emphasis on transparency and bottom-up management make great sense:

Transparency Management is the management of project stakeholders (sponsors, customers, project team) through the accurate communication of project performance metrics. In other words, accurate “Status Reporting”. If you gather detailed facts on where a project is doing well, where it is failing and who is responsible and accountable for the successes and failures, you have all the ammunition to mould, steer and direct a project toward project success. The first version of the UK National Lottery website was developed using this approach, and the project was delivered on budget, to time and meet the quality expectations of the client. When Transparency Management is working well it’s a joy to manage a project.

Bottom-up participation is a key component necessary to make Transparency Management work effectively. In its simplest form Bottom-up participation is about obtaining “project buy-in” and in it’s more complicated form it is the making sure that all product related tasks are estimated by the resources assigned to deliver them. Without this you are effectively running a “Top Down Project” where you are directing people to do things they may, or may not, agree with, and we all know what happens to projects where this is the order of the day.

So the next time you want to build a project, start and the bottom and keep all the lights clear.  Trust me, all your days will be "merry and bright," and there will be a much greater probability of "peace on earth, good will toward man."

Merry Christmas and Carpe Factum!

If the Project Doesn't Fit, You Must Quit

One of the great things about teaching the project management elective in the MBA program at Drake is the opportunity to introduce my students to real life field work in project management.  Specifically, I team my students with a local not-for-profit every year.  Their job is to create a business case and a project plan/charter for their clients.  My goal as a professor is to find a single not-for-profit which has multiple projects.  By doing so, my students must go beyond looking at the project to which they were assigned, and also look at other teams' projects as well.  In short, they learn a thing or two about managing a portfolio of projects for a given organization.

This year, we were fortunate enough to serve Hope Ministries' Bargain Center located in Pleasant Hill.  We had teams reviewing every aspect of their business, from accepting donations, to retail product flow, to retail space design, and many other issues.  It's a win for both the students and the organization.  And selecting a not-for-profit allows the students to get a taste of the triple constraint on steroids:  they never have enough resources or time, and they always have an abundance of tasks to be completed.

The challenge at the end of the class is getting all of the student teams to communicate with each other to figure out how all of the projects fit together.  Invariably, each semester, there is one project which doesn't seem to "fit" with the others (insert the Sesame Street song, "One of these things is not like the others").

I like to use the Johnny Cochran approach in the O.J Trial:  "If the glove doesn't fit, you must acquit."  However, in this case, it's the project that doesn't fit with the rest of them.  Saying it doesn't fit is not saying you will never do the project.  It's simply saying that right now, there's a project that does not fit with the current portfolio.

So how do you make the selection to determine what "fits"?  ProjectSmart, a UK-based blog, recommends having a project firing squad (OK, a little macabre on the metaphor front), but I like the idea:

• Know your current portfolio - what else are you working on and what needs your emphasis and attention right now?
• Well-defined selection process - eenie-meenie-minie-mo is not a selection process.  Figure out how potential projects will be scored and weighted.
• Identify the decision-makers - don't wait until the last second to figure out who has accountability for what lives and what dies.
• Make a decision - as they so eloquently put it, "the worst decision is indecision."  Don't be wishy-washy.

For the sake of academia, all projects survived (at least through the presentation).  What Hope Ministries does with the project recommendations... well that's ultimately up to them... but I am very thankful they let us play in their sandbox for a semester.

Carpe Factum!

It's About Time

Image by Getty Images via Daylife

Recently, I was interviewed by Kevin Eikenberry about my upcoming book on systems thinking for his series on process improvement.  One of his listeners asked how to deal with executives who claim not to have time for process improvement activity.  My response (which Kevin blogged about) was simple:  we're all given the same bank of time each day.  The same 24 hours are doled out to executives and entry level alike.

Based on a recent discussion I had with Lisa Gates, how we spend that time is a function of our values and priorities.  Executives with whom I've worked have been notorious for claiming they don't have time for all of this "project management stuff." Yet they scream the loudest when critical priorities are not completed on time or when corners are cut in order to make a deadline.

We also are sometimes challenged with individuals who do not complete their project tasks on time.  They manage to come up with numerous excuses why they were unable to meet their committed deadline.  It almost seems they put more effort into fabricating the excuses than they put into doing the work.  Jack Molisani of LavaCon recently shared with me a line he's started using:  "Don't tell me about the labor; show me the baby."

How do you prevent the last minute "I don't have time" excuse?  I make sure to check with my resources regularly two to three weeks prior to a task's scheduled completion.  I'll ask them if there is anything preventing them from completing the task as committed.  There will be a pulse check about any possible competing priorities.  I may talk with their functional manager if there has been a track record of resources being pulled at the last second to work on competing demands.  In short, I try to mitigate last second priority shifts.

What about you?  How are you ensuring your projects complete in a timely fashion?

Carpe Factum!

Bend your year for a bit?

Image via Wikipedia

Yes, it's November. The leaves have fallen. The Halloween candy has been ingested (resulting in a sugar high and subsequent crash). The malls are now playing Christmas music.

As project managers, we're all thinking about one thing: year end.

Let's face it, many projects will be coming to an end on or before Dec. 31. Generally, there are a whole heapin', steamin' pile of maintenance things to do, which tend to get bundled into their own year-end project. There are also numerous project constraints, such as increased time off by those project resources you seem to need the most. If your business environment is highly IT driven, then there is probably a "freeze" where no new programs can be implemented (so year-end processing won't be messed up).

Do you know what YOU need to do to prepare for year end? Well, let's do what Santa does. Let's make a list and check it twice. (Believe me when I say that project managers generally wind up on naughty or nice lists due to this time of year.)

1. Do you know what needs to be done by year-end? Is it written down? If you polled many of your resources about what they need to have done by year-end, what would they all tell you? Once you have everybody's input, does it align with the organization's mission?
2. Do you have a risk management plan? OK, every project should have a risk management plan, but let people know what can go wrong for the company if an important year-end project deadline is missed. Will customers be upset? Will fines and penalties begin accruing? Will critical data be lost or compromised?
3. What are the year-end priorities? Based on your answers to the first two questions above, what are the absolutely have-to-get-done items vs. the gee-it-would-be-nice-if-this-got-done by year end?  Treat your year-end initiatives like a reality show. Who gets voted off first and who gets to survive?
4. What resources are available to help you get done by year-end? This involves both people and budget dollars. If there are things that have to be done, do you have the people to work on them?  How well can they focus on them? Do you need to contract assistance to help get this project done?
5. What happens to your non-critical projects? Do you shelve them while everyone is working on year-end stuff? Do you keep them running on a bare minimum?
6. Have you laid out specific time constraints? Are there tasks to complete no earlier than Dec. 15?  Are there people gone the last week of the year? (I know, I know... people have personal lives around the holidays... crazy talk, isn't it?)
7. Last, but not least, do you have means of holding people (including yourself) accountable for getting everything done at the right time? How are you tracking it all?

So enjoy some egg nog, hang the mistletoe, throw in the Blenders Christmas and Carpe Factum!

Project Management Can Be Scary

Image by crowolf via Flickr

My apologies to Poe fans everywhere:

Once upon a year-end dreary, while I pondered weak and weary
Over many internet fantasy football's newly posted score
While I muddled, nearly napping, suddenly there came a tapping
As if some one gently rapping, rapping at my office door.
"Tis some janitor," I muttered, "tapping at my office door -
Only this, and nothing more

Ah, distinctly, I remember it was in the bleak December
With year-end data lying around me, piled high upon the floor.
Eagerly I wished the morrow - vainly I had sought to borrow
From my org chart full of sorrow - sorrow for the lost Lenore
For the fair and just project sponsor whom the C-Suite called Lenore -
Downsized here for evermore.

And the massive piles of data rustling, of each deadline bustling
Thrilled me, filled me with fantastic terrors never felt before;
So that now, to still the beating of my heart, I stood repeating
"'Tis some janitor demanding entrance at my office door -
Some late janitor emptying trash from at my office floor -
This it is, and nothing more."

Presently my soul grew stronger, hesitating then no longer,
"Yo!" said I, "You want my waste basket, my trash, and nothing more?
But the fact is I was napping, and so gently you came rapping
And so faintly you came tapping, tapping at my office door
That I wasn't sure I heard you" - here I opened wide the door -
Darkness there, and nothing more

Deep into cubicles peering, long I stood there wondering, fearing
Doubting things no mortal project manager did before
But the silence was unbroken, and the darkness gave no token
And my thoughts of project sponsors lost made me whisper, "Lenore?"
This I whispered, and cubicles echoeds back, "Lenore!"
Merely this, and nothing more.

Back to my computer turning, while my CDs still were burning
Soon my email made the tapping sound, much louder than before
"Surely," said I, "email, you ox, something in my Windows in-box
Let me see then, what the message, and this mystery explore -
Let my heart be still a moment and this strange email explore -
Tis an email, nothing more!"

Wish I could relive this odd tale, when I opened the strange email
Coming from the pompous head of Division Number Four
No apology nor excuse here, only threats and strengthened fear,
But this email came and perched on my wallpaper of Al Gore -
Perched upon ice caps melting just above my data store -
To be read and nothing more.

Then this simple email filing made my sad fancy into smiling
By the grumpy and the grouchy face unfortunately I wore.
"Though I sit here quite unshaven, over all my data slavin'
Ghastly grim and common email wandering onto my data store -
Tell me what thy purpose!"
Quoth the Scope Creep, "Do some more!"

Startled by my peace now smitten by reply so curtly written
"Doubtless," said I, "what he utters adds upon our project's score
From some sadistic master whose unmerciful disaster
Makes us work faster and harder than we ever did before
Said the email, "Do some more!"

Thus I sat engaged in guessing, but no syllable expressing
To this message which now threatened my performance score
In my chair I sat reclining, here now thinking of resigning
On the messy desktop's shining pile of crap from Division Four
But their manager, his message pressing me like ne'er before -
Quoth the Scope Creep, "Do some more!"

Then I felt the air grow stronger, stinking from durations longer
Made so by unnecessary tasks whose purpose shook my very core
"Jerk!" I cried, "how dare you do this, throw my project scope amiss
Now that I no longer have my fair and just sponsor named Lenore
Why, oh why, this kind of action from my dear and downsized Lenore?"
Quoth the Scope Creep, "Do Some More!"

And the email, never scrolling, all my changes now controlling
On the wallpaper of melting ice caps in honor of Al Gore
And his words have all the seeming of a demon's that is dreaming
Taunting, haunting me over the shadow of the downsized Lenore
And my soul from out that shadow lies floating on the floor
Shall ne'er be lifted till I do some more.

Originally published at www.carpefacum.com in October 2007.  But for anyone who's ever suffered scope creep, it's worth repeating.  Happy Haunting Season.

Who's The Baa's?

Recently, I helped shepherd a group of fourth graders through a field trip at the Des Moines Art Center (because being a project manager isn't masochistic enough in and of itself).  We received a highly informative and entertaining tour thanks to our guides.  At one point of the trip, we were looking at Francis Bacon's piece, Study After Velasquez's Portrait of Pope Innocent X, 1953.  Our guides knew how to talk with 9- and 10-year-old's and asked them who knew what a pope was.  Of our group, two or three were Catholic, yet not one even attempted to answer the question.

When I shared this incident among my Facebook friends, I was equally surprised.  One of my friends had enrolled her son in Catholic school for three years and he still didn't know who the Pope was.  Another of my friends suggested the Pope should open for the Jonas Brothers, which might help his publicity... that took us on a whole new direction of conversation I won't repeat here.

Occasionally people are unaware of who is in charge.

The leader (i.e. executive project sponsor or steering committee members) needs to make himself or herself known to the project  team and to the organization.  I have worked with large organizations enough to know that project teams often are unaware who is really calling the shots.  Some simple indicators to answer this question are as follows:

• Who owns the budget code of the project?  In other words, who holds the purse strings for the budget?
• Who screams the loudest about the project's progress (positively or negatively)?
• Who is identified as the sponsor on the project org chart?  (This may seem painfully obvious, but... well... you'd be surprised.)
• Who has the most at stake in the project's solution (and in the problem that precipitated the solution)?
• Who controls the resources working on the project?

There's an equally perplexing problem which is the converse of the one above:  If we know who the shepherd is, who then are the sheep?  Who are the identified resources for this project?  In my field trip example, I didn't expect the non-Catholic kids to know who/what the Pope is; they are outside the scope of his "resources."  In the same way, there's a very binary way to distinguish who the followers are on the project:  are they listed in the project plan, the statement of work, and/or the project charter?  If they've been identified (and presumably approved), then they're part of the project.  If not, then they are off limits.

Even then, you still need to identify your project followers in more detail.  I liked what Kevin Archbold shared in a recent post.  Project resources come in a variety pack.  You have critical resources, interchangeable resources, and warm bodies.  Just make sure people know who they are and what is expected of them.

Do you know who's in charge?  Do you know who's following?

Carpe Factum!

Dressing Your Projects to the Nines

Congratulations to Hubbell Realty for successfully completing their Hubbell Extreme 9 Homes in 9 Days Project... EARLY.  They successfully built nine row houses from foundation to completion in only seven and a half days.  I had the pleasure of catching up with Rachel Flint, Director of Marketing for Hubbell, who was kind enough to give me a tour the afternoon of their big ribbon cutting ceremony.

While this project is amazing from a community-building standpoint (it will provide needed housing for Anawim, a program for low income families), it's an even more amazing feat when you consider it from a project management standpoint.

1. Vision - Hubbell was first challenged with this project soon after completing an episode of ABC's Extreme Home Makeover.  About two years ago, they decided they would do this project of 9 homes in 9 days in the ninth month of 2009.  Since then, they have unwaiveringly stuck to their guns in completing this $1.5 million project.  Defining the end state is a key first step.
2. Reuse - ABC let Hubbell have their "playbook" for completing a project of this scope so quickly.  Rather than reinvent the wheel, they used what was already available.  How many of your organizations are wasting time inventing what's already there?
3. Planning - About a year ago, planning began in earnest, with the past few months seeing weekly meetings among all of the team leaders, trade partners, donors, etc.  People were held accountable for owning their part of the plan, defning their scope, and understanding the resource needs needed to get there.  Then they made sure all resources were lined up before the project began.
4. Document and Communicaate - There was one version of the truth for each shift and each work stream:  the playbook.  It was treated as the Bible for getting things done.  The week of execution, teams were working around the clock, and each shift manager spent as much time as needed to communicate critical issues and tasks to the next.
5. Check your Broader Stakeholders - The Des Moines Police stepped up patrols around the neighborhood and many organizations donated deeply (Rachel gushed about all of the restaurants who provided food for the workers).  A Senior Center voluntarily displaced themselves so Hubbell would have a command center.  ITA Group created a volunteer management database for tracking the labor.
6. Dedicated Resources - over 2000 volunteers worked around the clock for over seven days to complete this project.  Construction, procurement, and delivery were just some of the functions being managed.  Because of the strong vision and dedication, there was absolutely no infighting, drama, or office politics occurring, despite the large number of people involved.  Resources were color coded (blue shirts for volunteers; red shirts for team leaders).  Everyone understood their role and their tasks.
7. Tracking - the schedule was created in 15 minute increments (try managing THAT Gantt chart) with updates four times daily (at least).  Because they had accounted for everything that could go wrong, they never considered that everything could go right.  Hence, contractors were being brought in earlier.  They knew this because they had a plan and they followed it.
8. Communicate - since 90% of project management is communication, they not only created strong lines of communication internally, but Lori Blachford of the Drake School of Journalism spearheaded the social media aspect of this project, creating Facebook and Twitter updates, as well as Youtube videos.

So thank you, Hubbell...  Not only for contributing to the Des Moines community as a whole in a visible and positive way, but for providing us with an example of project management done very, very well.

Carpe Factum!

Is The Patient Ready To Go Home?

Those who have been reading my blog regularly know that I've been spending an alarming amount of my time in the hospital this summer. No, not as the patient, but merely as a concerned family member. This hospital time has allowed me to overhear a lot of conversations of patients who are about to be released.  Even more interesting, the cancer floor was just a couple of floors below the maternity ward, so many elevator rides were spent with departing new parents with offspring in tow. And a nurse giving last second instructions to shell-shocked adults.

If you think being in the hospital is overwhelming, try getting out (well, with the one obvious exit, but we won't go there). Leaving a hospital comes with volumes of information... from multiple doctors and specialists, from physical therapists, from dietitians and from nurses.  Most of the time, all of the information meshes well, but occasionally you catch conflicting data.

Your soon-to-be newly-implemented project is like a patient who is about to go home.  Many project teams make the mistaken assumption that a completed project means the "patient is healed."  Far from it.  Some project solutions take days, months or even years to become fully functional after their implementation.  Newly completed projects, like recently healed patients, need discharge papers to give instructions on what to do after the hospital stay is over:

• Change management - don't just throw the solution over the fence at the people who will be using your project solution.  Involve them early and often.  Keep them informed.  Listen to their concerns.  Use them as your sounding board and your cheer leaders
• Training - tag somebody who can spearhead bringing the organization up to speed on the use of your project solution.  Don't leave this up to chance.  You can be a success on schedule, budget, and functionality, but if nobody knows how to use the darn thing, your project will be perceived as a failure.
• Timing - if your project is big and complex enough, and if it's affecting enough people, are you going to roll it out in one "big bang" or are you going to phase it in?  How well does your implementation fit with the other projects in your organization?  Does it need to wait a while?
• Circle Back - talk to the people who wrote the original requirements for your project.  Does the final solution still look like it will solve the original business problem?  If not, why not?  Just make sure you close the loop to keep your stakeholders happy.
• Ongoing maintenance - the "patient" in my life is being looked over as she grows stronger and healthier.  Is your project being cared for by the right people?  Are there maintenance checks?  Are there service contracts?  Are future version control and upgrades being addressed?

Each one of these bullets could be a blog post by itself.  But if these items are found on your project "discharge papers," there is a much higher chance your project will go on to live a long and healthy life.

Carpe Factum!

How Much Bull Is In Your Project?

Anyone who has ever been to the Iowa State Fair knows how to locate the biggest and baddest of the state's livestock.  We have the "big boar" (and you thought your boss was bad).  We also have the big bull.  And let me tell you, it was a whole lot of bull this year... unless you're a project manager.

If you're a project manager, you've invariably had the the thought (spoken or not):  "I just wish I could do it all myself."  Whenever we have to rely on others, whenever projects are completed in a team environment, there is a certain degree of faith in other people to do what they say they are going to do.

Most of the time, we can count on others to perform.  However, there's the outside occasion when my BS-o-meter alarm starts going off, the when needle of dishonesty is edging toward the red zone.  Sometimes, this is due to ignorance... people don't know what they don't know.  Other times, the misleading information comes through maliciously in the status report.

If you are not the expert, how can you tell if the statements being made to you are honest?  How do you know if somebody is really 75% complete with their task?  When a teammate claims to be done with testing, can you take them at face value?

Here are a few pointers I use to keep everyone on the straight and narrow:

1. Create a culture of honesty - Robbins Gioia is a leading project management vendor.  Their code of ethical business conduct says it all.  You need to allow people to be honest and motivate ethics at every turn.  It only takes a single shot messenger to turn off everybody else and make otherwise honest people into ... well... something less desirable.
2. Watch out for timing issues - Boeing is experiencing this in a very unfortunate way with the release of the 787's flaws... which were now revealed the company knew about since June.  While one can only speculate the many reasons why the secrecy, it probably boils down to stock price declarations and annual reports.  But still... the stock market wasn't kind when the news came out.
3. Consider ulterior motives - when I talk to audiences about office politics, the first two things I tell people are to understand the "game" and the motives behind playing it.  Will people lose their jobs if the project fails?  Is there a huge bonus on the line if the project succeeds?  Who stands to gain?  Who stands to lose?  Ask GT&T if this is important.
4. Scrutinize the language - phrases like "experiencing delays" and "having problems" (with no back-up detail) are sure-fire red flags.  I also look for status reports to be in active (Tom will complete the testing plan on Tuesday) rather than passive (The testing plan will be completed) voice.  Then I look for what's not there.  Check out the last status report... it should provide some kind of projection for what should be reported this week.
5. Develop your own BS-o-meter - I'm a huge fan of Malcolm Gladwell's book, Blink.  Sometimes you just have to rely on your own intuition to tell you something is wrong.  But you can't rely on intuition if you don't develop it.  I've been hoodwinked on more projects than I care to admit, but from each of these, I learned what to look for on the next project.  I've known a few consultants who claim to be highly ethical and moral, except when they "needed" to lie to save their own skin.  You eventually get to know whom you can and can't trust.

So when you're visiting the State Fair, stop by and enjoy the giant bull.  Just don't invite him to be on your project team.

Carpe Factum!

Specific Generalities

Last month, when vacationing with the family, I happened across this sign by the side of the road.  Now one might think, "Items for sale?  Cool!  Where do I sign up?"  But this intersection of Pandora's Box meets Craig's List just gave me a headache.  What are the items?  How many are there?  Are they legal?  If not, can I get more?

Some of us like a little more detail before we part with our hard earned money.  At least a picture.  Or a description.  Or an interpretive dance.  But how many of you are going to fork over non-described sums of cash for "items for sale"?

But we do it all the time in project management arenas.  Read through people's project descriptions.  Or worse yet, look at their plans.  Ambiguous tasks.  Unclear requirements.  Uncertain results.  Vague activity.  Unclear direction.  Confusing communication.  And there you have it:  Items for sale.

Code Logics blog had a great post about how to build a solid project plan.  There's some great stuff in there.  The bottom line is simple:  BE SPECIFIC.  How?  Well, good project plans are just a collection of good project tasks... and it is not that hard to write a good project task. 

Let's look at how to do it the wrong way first.  Let's say you want one of your project resources to create a marketing campaign for you.  So you add the task "marketing campaign" to your project plan.  And the next day you get hit by a bus (a strong possibility here in Des Moines).  So your next-in-command picks up your project plan after your funeral.  "Hmmm," she muses.  "I wonder what the stiff wanted done with a marketing strategy?  We already have a marketing strategy."  (Okay, we'll hope she doesn't refer to you as "the stiff" ... but you get the idea.)

Now for the "right" way:

1. Start your task with an action verb:  Write, test, create, build, implement, et cetera.  Let everybody know what you are going to DO.
2. Follow it up with an object.  WHAT are you going to write, test, create, build or implement?
3. Add in any modifiers that will help you keep is straight from anything else you are going to write, test, create, build or implement.
4. Keep it under 10 words (15 if you are desperately verbose) per task.  If there's any detail, put it with the adjoining notes.  People want a project plan, not a dissertation.
5. Make it understandable... clear... beyond the shadow of a doubt... so a 4-year-old could pick it up and do it.

Okay, so maybe the last one is a bit tongue-in-cheek... most kids don't read until they're 5 or 6.  But unless your project is the roadside equivalent of "items for sale," do your team a favor and give them something a little more tangible.

Carpe Factum!