Here is a quote…

…Does this mean Microsoft Project is for everyone? Not quite. Many will argue that aside from the cost for infrastructure (which would be removed somewhat by the hosted solution path), there is still a valid reason to consider other solutions due to the unnecessary complexity of Project and concerns that it actually doesn’t handle projections reasonably.

We’ve met may people who feel the same way and get that single point estimates are a completly broken way to model future events. If you feel the real Project Management 2.0 wave is really about the way we model and manage projects (not just moving the old way to the web) then Jim’s post is a good place to make your voice heard.

In addition to ongoing performance optimization, we’ve added some new features in our latest release that allow you to do more in less time…

Under the ‘add’ menu you now have the option to Add multiple tasks - up to 20 at a time. You can also duplicate any item - project or task - which is especially helpful if you have multiple similar projects and don’t want to have to recreate the structure each time you add a new one.

We’ve also made some significant changes to the user interface (UI) in this release. Options formerly located on the ‘document’ tab have been merged into the collaborate tab. The new ‘history’ tab shows all of the changes made to the item since its creation.

Under the work detail pane, scheduling options ‘promise by’, ‘delay until’, and ‘on hold’ (formerly ‘don’t schedule’), are now on a new scheduling tab.

We hope these changes all add up to a more intuitive and useful product for you. Let us know what you think at feedback@liquidplanner.com.

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:

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.

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.

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.

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.

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.

Although I like to think of it now as steak tartar, we’ve been eating our own dogfood at LiquidPlanner from the beginning. I wish I had screen shots of some of the scaffolding UI that we had early on. Thanks to our uber-talented development team, it made a quick evolution to what you see today. This philosophy of also developing for ourselves has uncovered hundreds of opportunities –some we’ve responded to, and still others we’ve had to leave on the table for a while.

Deciding what to do next is sometimes tough. The night before our public beta launch at DEMO, my colleague Jake Gordon nailed it when he said, “We’ll know tomorrow what we need to work on tomorrow.” You gave feedback, we listened, and as a result, task dependencies will be in our upgrade to version 1.1 later this week.

I have to be honest – for a while, dependencies had fallen from the table to the floor. I’ll explain why as I beg you to consider carefully what you wished for and use the power of dependencies wisely.

Most of us on the development team have been forced to use or have willingly tried to use Microsoft Project at some point. One of the things we identified early on as a negative about the user experience was dependency maintenance. Because resource leveling sometimes behaved in unpredictable ways, hard coded dependencies were used to force logical scheduling. And Microsoft Project gave you an abundance of choices for types of dependencies, such as “finish -n,” where task B cannot start until task A is “n” days from completion. These types of dependencies falsely present themselves as reliable. In an uncertain world, you can’t always say that task A will finish in exactly 15 days, so how can you be certain that task B needs to start 5 days before task A finishes? For that matter, how can you say for certain that task B needs 10 days of lead-in time? Uncertainty is cold-hearted like that. The dependency above is actually not solving the real problem. It’s likely that task A needs to be decomposed further, because task B is dependent on some component of A.

Another issue with direct dependencies occurs when you need to move a chunk of work out of one project and into another. This is common for all types of projects. Just because you want to wait to do the fancy garden landscaping doesn’t mean you don’t want to do it at all. You’ll get around to it. Maybe just do the brick patio this go around. So you move that task or set of tasks into your project folder for Q4′08 … but if you have dependencies with items back in Q2′08…. I think you can see where this is headed. My prediction is you will next ask for a way to quickly delete all dependencies.

We honestly never missed direct dependencies in our development work, but we realize that we are only one data point. The automatic resource leveling / implicit ownership dependencies just worked in our case. In our small agile development team, we frequently are not working on our top task. We also don’t spend any significant amount of time moving items around in priority to reflect what we are working on. The idea is that even if you are context switching between three tasks, you still only actually work on one at a time and it all comes out in the wash. So if Jake needs something from me, he nudges me and then just works on the first task that’s not dependent on what he needs from me and life goes on. When we level set at mid-sprint, those items at risk are noted, adjustments are made and development proceeds. At the end of sprint, a decision is made as to the readiness of the whole feature.

We’re initially launching with simple Finish – Start dependencies. I can’t say for certain if more complicated forms of dependencies are on the table or not. It’s ultimately you who will tell me.

Next week, LiquidPlanner will be presenting at the Under the Radar conference in Mountain View. And just like at DEMO 08, we’ll have exactly six minutes to pitch the company, the product, and the business opportunity. (By the way, look closely at the rotating banner ad on the DEMO site to see a shot of Charles and Bruce in their on-stage glory.)

The audience? Press, investors, analysts, private companies, and other service providers. We’ll be sharing the “Work Together” session with our friends at blist as well as Cozimo and SlideShare. We’d love to meet you if you’re attending.