(continued from Part 1)

In Thornley’s post Social Project Management: Everything is Small Again which got me started, he has two lists of the “hallmarks of social project management (2.0)” vs “project 1.0 focused on large projects with large budgets and enormous teams”. Just contrasting those two in that way sets the discussion up to head towards a foregone conclusion; Smaller is easier to manage. Yet many projects are large projects and do require large budgets and teams.

A better question is, “How can we facilitate strong and healthy social interaction on all projects regardless of size/budget/staff?”

First let’s get some commonalities out of the way…

Common Ground

While they appear only on the social project management list, the following apply to projects of any size, so I’m taking them off the table for the purposes of this post:

• Smart, motivated people with multi-disciplinary skills.
  Yes, all projects should have these.
• Feedback
  Again, good for any project not just small ones.
  • Rapid release: Take it out to the community quickly and ask them to participate in alpha and beta testing.
  • Feedback: End user feedback is sought to refine the product.
  • Responsiveness: Speed and close contact with users leads to quick reaction to feedback.
• Minimal scope: Less is more. Build less.
  Nice buzz-phrase, but really more is more. However there is wisdom here. A series of small projects (less) can deliver more when repeated many times. Perhaps this should be “Build less at any one time.”
• Limited planning. Non-essential documentation and highly detailed specification are dispensed with.
  This is kinda like saying, “Don’t do non-essential tasks.” It is true for any size of project.
• Expected failure
  In projects of any size you can end up with expected failure when the schedule is unrealistic for the scope and resources. This is certainly a morale killer. But it is not limited to large projects

Now let’s look at some of the meaty problems with social project management in large projects.

Let’s get Small(er)

Breaking large projects down into smaller projects is an excellent way. In fact, Reichelt made a point of this in her presentation (though it does not appear in the derivative posts as other than a footnote). The issue, once you break the large project down, becomes tracking and coordinating all of those sub-projects that make up the whole.

This amounts to coordinating the efforts and communication and interaction of many people. This is a social activity.

Planning and Scheduling

Schedule actually does matter. You must set expectations with customers (either internal or external) on when your project will be completed. Business strategy often hinges upon your ability to accurately and reliably predict project schedules. Communicating those schedules and expectations is a social activity. It is why traditional project management tools that treat the schedule as somehow outside of the project itself, with no integration with discussion and notes and design is so… well… anti-social.

Long-term strategic planning requires something like horizon & beyond timelines. Planning a project now that will be useful and realistic in 18 months does not work at all if the project plan does not get updated anytime in between. Plans change, people change, organizations change, and the project plan must change with them or the schedule is surely junk.

However you schedule, it must be able to adjust effortlessly to fast pace and constant change. Gantt charts are simply a representation of the schedule that when mixed with single point estimates become poison. The optimism of these schedules (noted by Reichelt) and their lack of resemblance to reality spring directly from the way that the estimates for the individual tasks are collected, processed, and updated (or not updated as the case may be).

In order to get good, reliable schedule updates, there must be something in it for the person performing the update. They must be comfortable making the updates in real-time as they get improved information about their tasks on the project. It must deliver value to them independent of getting their boss off of their back. Otherwise all you get is grudging compliance and garbage data in the system.

Which brings up…

Continuous Updating

One of the key difficulties noted in managing large projects is that top down organization leads to an extensive hierarchy. Information trickles down but getting the information back up is difficult. Really this should be thought of as a pure communication problem (hmm… communication between people, social?).

If everyone can instantly see how changes (like scope creep) and trade-offs (like cuts) affect the schedule then the many stakeholders problem where the scope grows and grows from competing interests becomes easier (not easy, but easier) to manage.

The Wrap Up

There is little difference between the “social-ness” of small projects versus large projects. Social project management in large projects is not significantly harder than in small projects if you have tools that scale well and facilitate:

1. decomposition of large projects into smaller sub-projects
2. coordination of those smaller projects, and the aggregation of status and schedules for those smaller projects back into a large project view
3. flexible schedules supporting ranges of outcomes that encompass an uncertain future for realistic planning and scheduling
4. active participation by delivering added value for each participant in the project from the project sponsor all the way up to the front-line worker doing the day-to-day tasks
5. open communication and complete transparency with instant or near instant updates and communication of changes to all team members and stakeholders

This is in response to a couple of posts and comment streams about Social Project Management. The first was Joseph Thornley’s post Social Project Management: Everything is Small Again which was excerpted by the ZDNet ProjectFailures blog. All of this was kicked off by Leisa Reichelt’s presentation Social Project Management: Everything Small is Big Again at the Enterprise 2.0 conference. Reading Thornley’s post is worthwhile as it distills Reichelt’s slides into a list. Here are the original slides…

| View | Upload your own

I think it is misleading to say that social project management breaks down on large projects. All project management is more difficult on large projects. The social of it has little to do with the breakdown.

The promise of social project management comes from acknowledging that projects (particularly large projects) are a social activity. People doing work with people, for other people, with commitments to yet other people. The more people (i.e. larger projects), the more interpersonal interactions, the more social effects inside of the project.

In other words, the larger the project, the more important that you acknowledge and embrace the social interactions. Perhaps, dare I say it, even facilitate social interaction.

Software, particularly project management software, has tremendous potential for facilitating social interaction within a project. But if you ask most users they will tell you that their project management software does more to get in the way of successful social interaction than to facilitate it.

In part 2 of this post I’ll list out the main points of the issues and examine them in detail.

(continued in Part 2…)

Well, we’ve wrapped up the Enterprise 2.0 conference and officially launched!

We got covered by a buncha folks. TechCrunch wrote a little piece about our online project management solution. We also got some love from Kristen Nicole at Mashable who was one of the people I talked with at the DEMO conference back in January who really seemed to “get it”.

Liz took off to fly home a couple of hours ago and Jason and I finished the last few demos then broke down the booth. Just as we were wrapping things up and getting ready to shut down the computers Ameed Taylor from the OnDemand Beat Blog showed up. He asked really good questions and I’m looking forward to see what he writes about LiquidPlanner.

Overall this conference was pretty good. We launched our public beta at the DEMO conference and that set a really high bar for conference quality. But overall I feel pretty good about this one. We had good exposure to enterprise customers and what they are looking for in the next generation of project management tools.

The big take away for me has been the desire for integration between tool sets. Yeah, I know, people have been saying this forever so it ain’t any great revelation. But more than ever before I heard people being really specific about what they meant by integration. How they wanted each of their tools to play together.

Like many other venues the “2.0″ness of this conference tended towards the “we’re building social applications” and “employee genereated content” ends of the spectrum. But there were a few other folks who were doing things that didn’t (on the surface) look too 2.0-ish. Atlassian for one was there with a great integration story that included more than just their great tool set but “in the cloud” hosted stuff too. If you haven’t taken a look at JIRA Studio you should.

Anyway, I’m off to bed. We’ve an early flight tomorrow and I am still wrestling with the internet access in this darned hotel.

(Note: I had to post this later because of the Westin’s damned internet. Internet should be free in a business hotel just like the lights and the heat. Oh, and it should work too.)

After a relatively late night we got up and headed down to the booth.

While setting up the computers we lost internet connectivity. Turns out, many people had lost connectivity. Poor internet connection at a conference where cloud computing and SaaS is at the heart makes for very nervous, irritable exhibitors.We got things up and running though and then did lots and LOTS of demos.

I ran into several people that we met before at DEMO and at Under the Radar.

Jive’s booth is beautiful! The Blogtronix folks (that seem to be everywhere we are) were gracious and friendly as always. The more I work with tech people (particularly startups and small companies) the more impressed I am with just how nice and genuinely interesting most folks are in this crowd.

On the note of meeting lots of people… I need a better way to organize and process all the damned business cards I collect. Want a great startup idea; make a device that does this for me. I don’t care how, just make something cheapish that works and that is quick that I don’t have to think about. Please make it plug into my iPhone. That’s all I ask. Oh, and I want it yesterday.

Anyway, we wrapped up the day and then pretty much skipped dinner and went straight to the drinking. After spending the early part of the evening on a lovely downtown rooftop deck courtesy of Liz’s friends (who also fed us tasty snacks) we retired to the hotel bar.

After several hours, several drinks, and several interesting tales from some new Swedish and Norwegian friends we retired to our rooms to hydrate and prepare for the morning.

We’ll be up and at ‘em early tomorrow for the last day of the conference.

(Note: post publication delayed by Westin’s crappy internet access)

Well, we made it to Boston!

We all took the red-eye from Seattle and got right to work finding a grubby downtown diner to have breakfast in. Max’s Cafe… you can’t beat 3 eggs, homefries, bacon and toast for $5.00! No frills and quite tasty. However, it is friggin’ hot and humid in Boston. Liz thinks it’s just fine, but Jason and I are both thankful for the whole air conditioning thing.

The booth is roughly as we imagined it would be however none of the rented hardware was there. After a couple of quick phone calls it turns out that they just hadn’t gotten down the line to us yet. Note to fellow conference exhibitors… if this is one of the first times you’ve done this you should make sure you know what you’re renting. After the DEMO conference rental experience we thought that all items were ala carte. Turns out most computers usually come with those little things like keyboards and mice. So I didn’t really need to pack those all the way from Seattle.

Eh, live and learn.

I finished an interview with a podcaster. It went pretty well, but we’ll see what I sound like when it’s all edited down and posted. I’ll link to it off one of my next posts.

My friend from a conference at Penn State, Mary Sobiechowski, is here. She’s on a cloud computing panel where the CXOs (like her) get “pitched” cloud services by the likes of Google and Amazon. Considering Amazon’s down time recently they better have their rude Q&A practiced. Mary was nervous about the panel but she’ll rock it because that’s how she rolls.

We’re in the lobby right now eating some tasty, tasty calamari! Really, this is great stuff for hotel lobby fare. Liz and Jason are taking off to go to dinner with some of her friends from college.

I’m meeting up with someone I met at SXSW this spring to go get dinner and visit (at least one) dive bar. This is sounding like a perfect start to the conference!

Once again, the LiquidPlanner team is hitting the road! This time, we’re headed east to lovely Boston, Mass., for the
Enterprise 2.0 conference, June 9 - 12. If you’re attending, please stop by booth #707 to say hello.

We’re excited to show off the new features we’ve added since launch and talk to people about how LiquidPlanner can work in an enterprise setting — either by replacing or complementing existing tools sets. We’ve talked to hundreds of customers at businesses large and small, and one thing stands out: no matter the size of the company, the problems plaguing project managers and their teams are the same. We believe that finding project management software that works the way you work can be a big part of the solution.

After talking to a bunch of users I feel compelled to write this post on getting real about prioritization.

Folks, saying project A is higher priority than project B but you’re doing B first is ridiculous.

Project A may be more important than project B.

Project A may be of more value than project B.

But by definition, the one that you are doing first (in this example project B) has higher priority. That’s what priority means, you do it prior to anything else.

The problem seems to come from getting value and importance confused with priority. We like to think that we should be working on the highest value, important things first. That they should “take priority”. But let’s look at what happens when we blindly follow this rule…

Project Apple is a pretty important project and his manager Betty wants to make sure it gets done right away because it is “top priority”. She assigns the project to her rock star employee Abe. Abe starts work on Project Apple and 5 weeks later is about 1 week away from being done.

Betty then goes to a business strategy meeting where they determine that over the next few months the business needs more Bananas. Indeed, Project Banana is now more important than Project Apple.

Betty runs back to Abe and tells him that Project Banana is “top priority”. So Abe stops work on Project Apple and starts work on Project Banana. He’s making good progress and after a month is about done with Project Banana.

Betty meets with her manager to give him a status report on Project Banana. He thinks the company needs more cantaloupe…

Yeah, okay… it’s a little contrived. But you get the idea. With constant interruptions like that nothing ever gets completed. Since business value is typically realized after a project is completed, Abe is doing a bunch of work that is delivering no business value despite the fact that at any given time he is working on the “top priority” project.

So what went wrong?

Well, that’s what happens when you confuse importance with priority. If you want to see a fairly detailed discussion of why seeing projects through to the end, one at a time, without interruption gets you more business value in the long run even if you do the least valuable ones first, see my article on Multi-Tasking.

The reason this keeps coming up with customers is that LiquidPlanner forces you to prioritize your work. Our scheduling engine starts at the top of your priority list and works its way down, flowing the schedule out onto the calendar as it goes. If you want something done sooner, just move it up in the priority list and it will get scheduled prior to the things below it. But be aware, it will push out the dates for the things below it. That is the nature of making priority trade-offs.

But a lot of people want to say “this is top priority, but do that first.” Doing that is just fooling yourself. It does a disservice to your business, your employees, and yourself.

Understanding this should be your top priority.

Steve McConnell, author of Rapid Development and other great books on software engineering, has updated his list of software’s classic mistakes.

If you follow the link to the Construx site, Steve has a summary and links to more resources, but you’ll need to register for the extra stuff.

Looking at the list, we find some old favorites at the top:

1. Overly optimistic schedules
2. Urealistic expectations

But two new items have joined the fun this year:

1. Confusing estimates with targets
2. Excessive multi-tasking

J. Peter Bruzzese has an interesting post over at InfoWorld that might be intersting to the LiquidPlanner community entitled Microsoft’s Enterprise Project suite isn’t just for the enterprise.

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.

Do More in Less Time

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.