Archive for the ‘Scheduling’ category

My daughter ran in the Grand Rapids Marathon a few weeks back. She finished in 4 hours and 30 minutes, which I believe is a respectable time to run 26 miles if you’re not from Kenya. One of the things I learned from her preparations is that you have to have a “plan” for your race. Her plan, apparently, was to use her heart rate to determine how fast to run each mile, striving to keep a relatively steady beats per minute, which may lead to less buildup of lactic acid or other ‘cramp inducers.’ Near as I can tell, she ran the first half of the race just slightly slower than the last half, but kept a pretty steady pace throughout. Good for her!

I have decided, though, that if I ever run a marathon, I will take a vastly different and obviously superior approach. I will jog the first 16 miles of the race and then sprint the last ten. I am pretty confident I can beat her time by doing that. I can jog 16 miles briskly in about 3 hours, and then sprint the last ten at ten miles per hour, in another 60 minutes, finishing in 4 hours. Take that!

I was committed to this plan until a few friends asked some probing questions like, “Bob, have you ever sprinted ten miles?” Brutally, they followed up with, “Have you ever sprinted even two miles?” And then, the coup de grace, “Have you ever sprinted even one mile after jogging 16??”

At that point, I realized the flaw in my plan. Trying to go faster at the end of a long race is no strategy for success especially if:

a) you’re out of shape or

b) you’ve never done it before

So why do so many project teams and project managers think they can get to the halfway point of a project in six months and then finish the other half in two??

Maybe it’s always been this way, but it seems like lately every time I ask someone how they are doing, they say, “good, busy…” It appears that, perhaps without even being aware of it, we have all succumbed to the “busyness” bug. You think you’re busy? Look at me! I’m three times as busy!! I am late for all the meetings I am supposed to be at, and at least twice a week I tell people how I can’t make it to their meeting because I am already triple booked. And if you are lucky enough to get me to attend your meeting, I will have my iPhone in my hands the whole time, checking email, texting other meeting attendees, and generally squeezing a few more messages into my already “busy” day. And if you hadn’t noticed, if I am busier than you, I am also more important than you… The busier, the better…

Admit it. If you asked a colleague how it “was going?” and they said, “pretty good, not much happening, only have one meeting this week, kinda looking for a new project, you know, something to sink my teeth into, I have quite a bit of spare time right now…” you’d be aghast! What? You’re not crazy busy?? You must be, wait for it… expendable.

But this approach does not end well. I think I can safely introduce this sketch from the old I Love Lucy show to a new generation who may not have ever seen it.

To continue to accumulate more and more work (or just say you have it) does not improve the quality of what you do, your ability to be attentive, or your stress level. And I think that’s part of why unemployment is still at close to 10%. If I hire someone to help with our workload, we might not be as busy. That’s bad, right??? Or is it?

Think about the worst road trip you ever made. Maybe you and a few friends were driving to spring break in Florida from Michigan in an old, unreliable car and it broke down somewhere in Tennessee and it took you 4 days to get it fixed and get there. Or maybe, like me, you were driving to a friend’s wedding in Cleveland and you hit a snowstorm and all of a sudden you were going 5 miles per hour for miles on end. Or maybe you hit traffic on your way to the Hamptons over Labor Day and a 2 hour drive turned into a sweaty, frustrating, 4 hour ordeal…

Here’s my point. Those things happen. But when you sit down to plan out a trip and use Mapquest, for example, it doesn’t predict any of the problems we listed above. It simply takes your starting point, your destination, the approximate number of miles in between, and an average speed and calculates your arrival time. Mapquest operates in what we might call a ‘best case’ scenario. No flat tires, no horrific traffic jams, no accidents, no thunderstorms, etc. And that’s OK. Because any prudent traveler with a really tight schedule where being late would be a real problem (like a wedding, flight, or graduation ceremony, to name a few) usually leaves ample time in addition to what they were told by Mapquest “just in case…”

So why don’t project leaders planning software development or other IT projects do the same thing?? How many projects have you been on where:

a) No one held a meeting to brainstorm all the things that could go wrong?
b) Someone held that meeting, shared the list, and left it at that?
c) Someone held that meeting, shared the list, quantified the risks, but forgot to incorporate those risks into the project timeline?

Next time you are working on an IT project that is late, ask yourself some tough questions. Are we really late, or did we simply build a project plan that was a ‘best case’ scenario? Did things happen along the way that your experience told you could really derail things (like a flat, traffic or an accident) and you just ignored them as you merrily entered tasks and durations into Microsoft Project? Is it POSSIBLE that it was your OWN FAULT that you just missed your flight???

There are lots of techniques for dealing with this in project planning. Monte Carlo simulations and other probabilistic methods offer ways to develop a range of finish dates, rather than a single finish date. Or even two project plans: one that’s best case, and one that’s worst case. Present them both to your stakeholders. See which one they like better (I am guessing the best case one, but at least you tried…) And just remember that most project planning tools are like Mapquest: start, finish, distance and average speed. If you don’t take it upon yourself to model in the other unknowns, as Jimmy Buffett said in Margaritaville, “hell, it could be my fault…”

We lost our electricity from wind storms in Michigan over the weekend. With little or no warning, other than the howling of the wind, your lights can go out in an instant. If you’re like me, you begin the process of speculating where the flashlights are and hoping they have batteries in them. But most of all, you wonder when the lights will come back on. It’s not trivial either, because you will make very different plans if your electricity will be out for days versus hours. But how will you find out? You certainly can’t go outside and determine exactly where the break in the system occurred. You may not even be able to get through to the utility company, since they are typically inundated with calls during a widespread outage. You start to worry about no heat, frozen pipes, spoiled food, and no water (if you have well water with an electric pump like I do).

Two things made this most recent outage a little easier. First, there were pictures in the news and on the web that showed line workers in bucket trucks working to remove downed tree limbs, restore lines and reconnect the grid. Second, our utility has an automated service that you can call and punch in your home phone number. They resolve that to an address, and then tell you when they currently predict your service restoration to be complete.

That got me thinking about the need to communicate to all stakeholders on IT projects and how critical it is to get them ‘out of the dark.’ They can’t see the configurations you’re changing or the code you’re writing. And even if they can, they can’t relate that back to exactly when a certain module or aspect of functionality will be available for their use.

Whether they are in sales and marketing, chomping at the bit to sell the new software you’re building; in finance and accounting, waiting for an electronic interface that will save them hours of manual data entry; or in plant operations, hoping for better insights into how they can reduce or eliminate costly production defects, they are relying on you to tell them when that day will come.

So next time you think that status reports are a waste of time or that the system “will be ready when it’s ready” or that demo servers are a pain to build and maintain when you have real work to do, remember what it’s like to be the one in the dark. Be a little more open to sharing what you know with someone who doesn’t…

I watched the Dark Knight two weekends ago. What a great movie! Action-packed, with cool special effects and, as you’ve probably heard 1,000 times by now, an awesome performance and interpretation of the Joker by the late Heath Ledger. I certainly would not be giving the plot away by telling you that Batman, Commissioner Gordon, and the other “good guys” in the movie find themselves repeatedly in a predicament brought on by the many evildoers in the film. And once they see the fix they’re in, here’s what they say to reassure each other, – “I have a plan.” Inevitably, when the plan doesn’t seem to always work quite the way they hoped, one of the heroes will turn to the other and say, “Now what??”

I think that summarizes my view of technical project management pretty well. In technical projects, we only know a few things at the outset:

We’re better off with a plan than without one.

Not long after we get started, something is going to happen to make the original plan obsolete.

How we handle things from that point on will likely determine the success or failure of the project.

And so, here are a few recommendations for making your projects go a bit smoother in the new year:

1. Before your project starts, have a plan and LET OTHERS KNOW you have one. If it’s in your head and nowhere else, some of those faithless cretins you work with won’t believe you have one and they certainly won’t be able to try to understand and follow it.

2. Expect it to change and decide how you want to deal with that. One of the ‘classic’ project management concepts is the idea of a Baseline. [for a quick sidebar definition, baselines are essentially snapshots frozen in time of the project, schedule, scope, budget or all of the above] I believe that most of the baselines created in MS Project and other tools are there for all the wrong reasons. Namely, to protect someone contractually, to play some dysfunctional game of “I told you so” or to bayonet the wounded at some point in the project.

So here’s a radical idea. Before you set a project baseline, establish a reason why you’re doing it, and get concurrence from all your stakeholders. Then, when the project changes ONLY refer back to the baseline for that reason. For everything else, use only the adjusted project plan and move on. You’ll have a mentally healthier project team, among other benefits.

3. Be aggressive in answering the inevitable question, “Now what?” By that, I mean don’t fall into the role of the convenient leader. Convenient leaders, by my definition, are happy to be designated as the Project Manager or some other fancy title of pseudo-importance until something goes wrong. Then they act as if the solution, like finding more funding, is the CFO’s problem, not theirs. Let’s take a relatively serious situation as an example:

You are the project leader of a complex, custom development project. Even with few scope changes to date, you start to realize 5 weeks into the code development phase that the estimates for the effort were too optimistic and that, if you’re lucky, the code will get written only 50% over the budget. Now what??

First, acknowledge the problem openly and do your best to quantify it.

Second, remember that this is SOMEBODY’S real money. It may not be yours, but you don’t want to get lumped in with all those fund managers at Wall Street brokerage firms.

Third, seek creative solutions from the team and any other trusted or involved sources. It’s your job to acknowledge that the problem exists and to communicate that, but not necessarily to solve it on your own. The folks closest to the problem, aka the development team, are also the most likely to come up with some options for how to proceed.

Lastly, don’t sulk. I suspect you deal with similar crises often enough in your personal life not to be shocked, like when the new suit you were going to buy ends up being a muffler on your eight year old car instead.

I have been listening and waiting patiently, while watching one of the many shows on the History Channel, the Discovery Channel and the Egyptian Antiquities Channel (OK, fine, I made that last one up…) for one of the pyramid experts to sit back smugly in his overstuffed chair and say, “They’re just a pile of stones, how hard could that be???” Needless to say, that never happens. Instead, they go one for hours, puzzled and amazed, giddy about the engineering and construction feats of these ancient Nile Valley dwellers.

Granted, I am amazed as well. But why can’t just a smidgen of that appreciation spill over into our software universe? What are we doing wrong??

I was with a client for two straight days this week, acting (and I stress acting) as the subject matter expert for an enterprise Project Management Office and Decision Support System for the government of an emerging third world country. For a day and a half I patiently gathered requirements, sketched out architectural alternatives and tradeoffs, and modeled data flows.

Toward the end of day 2, I had the audacity to imply that to electronically and ‘automatically’ provision new projects in the EPM tool of choice from a legacy budget authorization system might be technically challenging (not impossible) and could involve things like workflow and transaction management. I stated my case in layman’s terms.I was brilliantly articulate. Not condescending at all, just enlightening.

I paused at the end of my explanation, sat back, and waited for the nods of understanding. “Ah, that was wise, Bob. Thank you. We didn’t really appreciate the complexities of trying to do this in Phase I.”

That’s what I expected to hear. But you already know what happened, don’t you? Their body language said, “How hard could that be??” Their words said, “We really need it to do that.” Their faces showed disappointment. I, of course, relented (who wants to disappoint a client?) and said, “I am sure we can figure out a way to make it do that…”

We are nowhere.

Gone are the days when hulking mainframes lurked in a data center behind security doors, air-conditioned to a temperature you could keep Dove Bars in, when the general public had a fair amount of awe and respect for the “programmers” who made these machines do their bidding. Since then, end user expectations have gone up. Appreciation for the inherent complexity of software has gone down. And with that, quite a bit of whatever mojo we ever had.

I am in complete awe of what you can do with an iPhone and the remarkable engineering feats that must have made that possible. Am I the only one?

With the same determined spirit that keeps us going when there are more bugs this week than last week, let’s vow to take the time to educate and enlighten one end user. No matter how long it takes and how persistent we have to be, let’s find a way to help them see that software engineering is still challenging and its practitioners still worthy of some level of admiration. Even if we’re not piling stones on top of each other…