We are a week behind our original target release date but we are pretty happy with the sprint. Assuming nothing comes up with our final testing, the new code will be available by this time next week.

Of course we use LP for managing everything. Above, you see our workspace showing the total work for the release (features, bugs, operations, and loose ends).

Let’s see what we can learn from the work trending:

Some of the obvious stuff is that we pre-loaded the sprint for over a month before starting work. Remember these graphs show total work in the project containers. That takes us to the first peak at which point we were overloaded and red flagged. We had the planning meeting, cut scope and then started working on the sprint (green part).

For this next part, it helps to understand the Cone of Uncertainty. If you don’t know about this, I recommend you take a minute to follow the link to the Construx site. Here is the short verion: its a way to think about what should happen to uncertainty as you work your way through a development process:

Laying the Cone of Uncertainty on our actual results is interesting. Anything stand out? Perhaps that big surge of scope creep in the middle?

It’s exactly what it looks like. We added work when we were not supposed to, we under-estimated a couple of things, and we didn’t plan enough time upfront for working on bugs found during the sprint. Heck we rode the whole sprint with those red flame icons staring at us in the face. We had to make a few cuts and work a few weekends, but at least we had full optics and a lot of fun the whole way.

Anyway, you’ll have the new code soon. Here is a peek at one feature, the new bulk add:

In project management, we tend to focus on the method. And there is no shortage of methods (Six Sigma, Scrum, Waterfall…). The method is the what of project management and is often at the core of an effectively run project. But the method can only take your project so far.

Really, it is the approach, or the how, that separates great projects from the merely good. And lets great project managers rise above the rest. The good news is that there is an effective approach to complement any method.

The how permeates every aspect of a project. It is the way you communicate, the way you solve problems, the way you lead. You may have a full tool kit of project templates with orderly steps to follow, but if you can’t effectively solve a problem with efficiency, competence, and finesse, your tool kit isn’t going to be worth as much. After many years of real world experience, our team has learned that the how is what creates client satisfaction.

Here are the top five traits you need to master the how of project management:

1. A collaborative management style. A collaborative management style engages the project team and key stakeholders in problem solving and decision making. Words like “trust”, “buy-in”, “ownership”, are used a lot.
2. Adaptability. An effective project manager is one that can quickly assess a new situation and adapt to the existing situation. If structure is needed, then add structure. If the project pace is fast, adopt a fluid approach. And so on.
3. Figure-it-out resourcefulness. As a project manager, you are often not the subject matter expert (SME) on any given project. You probably rely on others to bring important knowledge and know-how to the table. A good project manager is creative, tenacious, and knows how to use SMEs and other resources effectively. They also know that the best results often emerge from out-of-the-box thinking and the will to try, and try again.
4. Highly developed communication skills. Communication is king for project managers. To succeed, you’ve got to excel in all aspects of communication. For example, knowing when it’s appropriate to pick up the phone, send an email or request a face-to-face discussion. Or knowing how to engage with an executive or motivate a team member. Every team and every project is different, so you must be able to customize your style to their needs.
5. Flexibility. You’ve heard it a million times: the only constant is change. But how you handle change can make or break any experience-and any project. Flexibility engenders creative thinking, which no project could succeed without. When you stay open, people and their ideas feel welcome. But if you become too rigid, the flow stops flowing. The whole project dynamic can percolate with enthusiasm or fizzle with frustration depending on your flexibility as a leader.

So now you know some of our secrets. Now let’s hear about some of yours.

==============================================

Joli Mosier is a founding partner of MosierMcCann, a Seattle-based project management consulting firm serving clients like AT&T, Expedia, Sur la Table, and more. MosierMcCann offers on-the-job project coaching to teams needing the tools and guidance to develop their key team members.

We’re getting into full swing here at LiquidPlanner. The application is pretty solid, there are a few features we’d like to add (aren’t there always), but for the most part it is ready for prime time. So we’ve been beating the bushes to get some of our better beta customers to sign up to actually give us money. This is a big thing. While people are willing to put up with quite a bit when using free software, if they’re willing to pay for it that really says something.

But there’s one thing that’s been bothering me during my conversations with folks about what they want from a project management tool. They are looking for a new tool because their projects are out of control, late, over budget, under scope, or… well… let’s just say that if there is a way that things can go wrong someone somewhere is experiencing that particular flavor of train wreck. Almost uniformly what they want is a tool that they buy, turn on, and magically their problems are solved. They want a silver bullet.

There are no silver bullets.

No tool or piece of software can make you more efficient or better at what you do unless you change the way you do it.

This isn’t some great revelation. I’m certainly not the first to say it. It continues to amaze me how many people say, “Our projects are not running as well as we’d like so we want a tool to help and we don’t want to change anything.”

If you don’t change your behavior then things will stay the same. A good tool helps you (and your organization) understand what needs to change. A good tool shows you the effects of any changes you undertake. But notice, the tool doesn’t do the changing, you do.

When I was a kid I was into ski racing. No really, this is relevant so just stay with me.

Anyway, I knew I had a problem with starting my turns too late. I knew it because my coach said so and my times were slow and not improving. Then one day a better tool showed up. The coach brought a camcorder up to the hill.

He would record us coming down through the gates. At the end of our run we would watch the recording right there. And then we’d go up and do it again.

I swear to you that I was faster within the first two runs. I could see what I was doing and get nearly instant feedback. I made more progress in that two hour session than I had made in a month of the coach telling me what was wrong.

But the camcorder did not make me faster.

It wasn’t the tool, but rather the change in my behavior that made me faster. If I had said, “Just give me a tool that will make me faster but I don’t want to change the way I ski at all” the coach (and I suspect all of you) would have laughed at me.

Project management software is like that though. People are always looking to the software to adapt to their pathological, dysfunctional ways of executing projects. They don’t want to change the way they do projects. If you don’t change the way you’re doing things you will continue to have the same level of success (or lack thereof).

There’s a great list of 50 reasons not to change that sums up just about every one that I’ve ever heard. Thanks to Raven for pointing this out to me.

In the process of building our online project management software I got to thinking about what online has to do with project management. The fact that LiquidPlanner is multi-user and web-based creates a whole new set of interactions that go way beyond what desktop project management software does and has to cope with. For starters it acknowledges that project management is a social activity.

It comes as a surprise to some folks that I say project management is a social activity. They typically think of it as something done with software to generate schedules, or with change management tools, or with budgeting tools; they think of it as something technical. Tools like Microsoft Project and its online clones were born from standalone desktop software and so they’re firmly rooted in single-user behavior. In fact, they only place a thin veneer of multi-user functionality on top of the Gantt chart and guesstimate paradigm. In effect they deny that project management is a social activity.

But project management is about people making commitments to other people to work with still other people to get something done or built for perhaps some other people. Project management is about people. If that’s not social then I don’t know what is!

Still the tool set that most people work with does little to get folks to work together in a productive little mini-society. When you have one project manager controlling the scheduling tool and workers being held accountable to wild ass guesses that were made by someone who “used to do this job 15 years ago” and who “really knew how to get things done back when things were hard” you are not going to get one big happy family. The tools strongly affect the culture of the project team.

Being an online tool for project management unlocks and brings to the surface much more of the social interaction that you see inside of projects. There are people out there that just don’t “get” why you build something like this as a web-based application. They are absolutely correct in thinking that maybe you don’t need your single user text editor as a webapp. But then the thinking stops there.

It is like saying, “I don’t understand why Facebook is on the web, it should be stand alone desktop software so it performs better.”

Sure, the data transfer and the user interface would perform faster. But perform better? Perform what better? Perform social activities better? Gimme a break!

These folks think that we’re just reinventing the MS Project wheel on the web.

But we’re not. We’re building social software to enable healthy projects.

That means LiquidPlanner needs to be on the web (not just passing data over the internet). LiquidPlanner needs zero installation barriers so anyone can use it to actively participate in project management. LiquidPlanner needs this for the same reason that any social application needs it; because it is the lowest barrier way to get good social interaction.

All of which comes from simply acknowledging that we’re building social project management.

On Monday I attended an Executive Breakfast put on by Construx Software. Steve McConnell, renown author of books like Code Complete and also one of our advisors, discussed the “10 Deadly Sins of Software Estimation.” Not surprisingly, most of the audience chuckled knowingly after each “sin” was read aloud. And even as one of the few non-developers at LiquidPlanner, I found many parallels to the stuff that goes on in marketing projects I work on.

The very first sin actually struck quite a chord: Confusing Estimates with Targets. It’s not uncommon that people use the word “estimate” when they really mean “target,” or maybe even “commitment.” Here’s the kind of dialogue that goes on quite often in project meetings.

Project Manager: “Chris, how long do you think it will take you to make that change?”

Chris: (on the spot) “Umm. Hmm. Maybe four days? Maybe six?”

Project Manager: (scribbling away) “Great, gotcha. So Tim, how long will it take you…..”

Wanna bet that the PM wrote down four days next to that task? Wanna bet that Chris didn’t really think about what he might be signing up for when he “estimated” that task?

Say you have a project that needs to be completed by June 1st — that’s your target date. What do you do next? Do you create a work breakdown structure, estimate your tasks, and hold your breath that the schedule says you’ll finish on time? If not, do you go back in and reduce all your estimates, just so your dates match up?

That kind of habit seems to be a pretty clear recipe for failure. By clearly separating estimates from targets or commitments in your project plan, you can set expectations up and down the chain. If your schedule says you’ll run over, you can have a real conversation about cutting features, adding resources, or maybe even the need to plan for overtime. (In LiquidPlanner, we use “promise dates” (denoted by the diamond symbol on your schedule) to set targets, and ranged estimates to create schedules that capture uncertainty.)

Managing project schedules is really about the iterative process of bridging the gap between the target date and the estimated completion date. Kudos to Steve for bringing to light the fact that this is more than a semantic difference.

We’ve launched dependencies!

Last night the team stayed up late making sure that the update to the site went smoothly. This morning our users were greeted with dependencies. This is a big deal for us as we were getting quite a few requests for dependencies. In fact, several people asked us why we launched without dependencies. I thought I’d take a minute to talk about that.

I have a love/hate relationship with dependencies. When we designed LiquidPlanner we realized that when you put all of your tasks in priority order you just don’t need that many dependencies. The reason being that if Task-A needs to be done before Task-B you just drag it up above Task-B and (provided they’re assigned to the same person) Task-A gets scheduled before Task-B. So if you slice your big projects up into small enough pieces (say by doing Scrum with one month sprints) then the whole “need” for dependencies just gets a whole lot less urgent.

We have been using LiquidPlanner to plan our internal work since about April 2007. It is now a year later and we have added dependencies, but we never really missed having them. In fact, one thing that dependencies do is make your project plan brittle. They make it hard to alter the plan without breaking a dependency or messing something up. That is not to say that the project can’t change easily, just that the project plan cannot. This is kind of an artificial penalty for updating your plan to reflect changing reality.

I am all for moderate use of dependencies to build project plans. But I think that products which demand that you put a bunch of dependencies in place in order to get a halfway sane plan have trained many project managers to bad habits. They’ve become addicted to dependencies. And the more you use dependencies to solve your scheduling problems the more brittle and hard to maintain your project plan becomes.

So before you add that dependency ask yourself, “Do I really need this?”

Because if you can just prioritize the work earlier then you’ll end up with a schedule that is much more flexible and resilient to the change that inevitably occurs when a project plan meets reality.