Mike Coyle’s Weblog

A couple of months back, I had the pleasure of being interviewed by Susan Ladika for PM Network magazine (a publication of the Project Management Institute). They were doing an article about managing small project teams for the March 2008 issue.

I put together a bunch of content in advance of the interview. Now that the magazine’s hit the streets, I figured that I’ll publish the stuff that I wrote that didn’t make it into the article.

I did my prep work by writing out a fake interview with myself. I’m certain that I’ll recycle some of this content in future writings and talks, but here it is in its original form for your reading enjoyment:

–[BEGIN FAKE INTERVIEW]—————————————–

1) Your company uses the slogan “We help small teams solve large problems.” Please explain.

The needs of small, disciplined project teams are largely unrecognized and under-served in the project management community. We started our company to bring the necessary people, process, and technology to small teams so that they can leverage their constraints and deliver value to their customers in a predictable and instrumented fashion.

Too many small project teams either wander their way through the project lifecycle alone, or end up suffocating under a heavy, inappropriate layer of bureaucratic oversight that makes project delivery slower and more painful, but doesn’t necessarily reduce any tangible delivery risks.

We know that there’s a better way, so we put our money where our mouth is. ProjectPipe.com is our project management software solution that embodies our approach to disciplined, high-performance small team project management. Our target customers in corporate settings are the small boats of ambition floating in the sea of big company mediocrity. While we’re not here today to discuss ProjectPipe, any interested readers can find out more at ProjectPipe.com.

We are convinced that the future of project delivery is small, distributed teams. We are fortunate to be in a position to expedite this trend through our software, consulting, and writing.

2) But isn’t bigger generally better?

No. Having more people on your team is not like having more money in the bank.

For example, jazz quartets don’t want to be orchestras when they grow up. The two are different beasts.

If you try to run a jazz quartet like a symphony, you get bad jazz. Run a 20-piece orchestra like a jam session, and you end up with chaos. The same goes for project teams. If you run a small project like a miniature large project, you end up with….pretty much what you see in corporate environments everyday. Namely, too many meetings, lots of low-value boilerplate documentation, and other adminstrative overhead that gets in the way of solving the real problems at hand.

Don’t get me wrong, a team of 4 people still needs to play by the book, but it’s a different book.

3) Why does the size of a team matter? Aren’t there universal best practices for project management?

At a high-level, there are a number of universal truths that the Project Management Institute, and other organizations have done a wonderful job categorizing and articulating. However, when it comes time to tactically implement these best practices, you see the entire spectrum of implementation choices, from hyper-bureaucratic process overkill to Wild West-style chaos.

In theory, practice and theory are the same. In practice, they are profoundly different.

This is why it is so important to have strict adherence to a lightweight process. As a project manager, you want to spend your overhead capital wisely, applying documentation and other process-related protocols to the specific areas of project risk that are relevant to your project.

4) What types of things are more difficult for small teams, aside from the shortage of manpower?

There are three general challenges for a small team. First of all, distractions and overhead can be a significant drain of time and attention. Second, context switching can be expensive, as members of small teams often wear multiple hats. Lastly, having fewer team members to draw insight from can result in less diverse domain expertise brought to the table.

5) Are there any advantages that come from having a small team?

Certainly. Small effective teams understand the nimble clarity that comes with having few moving parts. They have conversations rather than meetings.

Small teams separate the wheat from the chaff, since there’s nowhere for underperformers to hide. As a result, I’ve found that higher-skilled resources are more likely to prefer working in smaller teams, since there’s a bit of self-selection at play. For example, rock stars know that poor performers are more interested in being the 16th person on a 16-person team than the 3rd person on a 3-person team.

6) What kinds of special needs do small teams have?

Small teams need to behave like small teams, not miniature versions of large teams, because bureaucracy doesn’t scale down particularly well. Small teams need to be led by a project manager that understands the dynamics of small team delivery. Specifically, someone who picks their battles carefully and doesn’t mind getting their hands dirty from time-to-time. Additionally, small teams need to use the best tools available, as they cannot afford to arbitrarily throw labor at problems.

7) Are there particular issues that come when team members are dispersed around the globe?

Small teams should strive for “location transparency”, regardless of the team’s physical locale. Collaborative technology (and the day-to-day practices that support collaborative processes) should be employed whether team members are separated by a hallway or an ocean.

8) What ways can small teams work most effectively to accomplish big tasks?

There are four aspects that drive small-team effectiveness: Planning, Process, Automation, and Asset Management.

• Planning: Small teams need to focus their efforts on understanding how the key moving parts of their project fit together so that they can proactively categorize and manage delivery risk. This is far more important than trying to optimize the workload balancing in your project plan, since you’re not trying to distribute lots of work among interchangeable resources on a large team.
• Process: Small teams should maintain strict adherence to a lightweight process. Individual heroics are not scalable nor predictable over time. Even small teams need to play by the book, but they need to make sure that it’s the right book for them.
• Automation: Small teams need to maximize the amount of work that they don’t do, and focus their efforts on the important stuff. If work cannot be avoided, it should be automated. Computers are really good at doing predictable stuff really fast.
• Asset Management: Small teams should manage their important data using some sort of version control mechanism. A good version control system acts as a time machine in case users need to review and/or compare previous versions of a document or other artifact, and a bank vault to protect a single, current version of the truth for each project asset.

9) I also found the comment intriguing that large teams are usually bands of small teams in disguise, and I’d like your thoughts on that.

We coined that phrase to help decision makers understand the true nature and composition of their organizations, and soften any negative connotations that the “small teams” concept would have in larger organizations.

At the end of the day, projects get talked about by large teams and completed by small teams (or groups of small teams working together).

Any team can make a decision. Only small teams make great decisions.

Any team can do work. Only small teams do efficient work.

It’s true that there is strength in numbers, but sometimes that strength lies in small numbers.

–[END FAKE INTERVIEW]——————————————

Python.org has a number of very interesting Success Stories of how various organizations are using Python to solve real world problems. With all of the focus on web development frameworks and such, it’s interesting to see the diverse set of problems that Python is addressing every day.

In our new case study titled Botonomy Uses Python to Create ProjectPipe.com for Web-based Project Management, I give a high-level overview of both the “why” and the “how” behind ProjectPipe.com, our hosted project management solution.

The article talks about the problem that we set out to solve, and walks through one of the more detailed “behind the scenes” overviews of ProjectPipe that we’ve published to date.

How did The Little Ol’ Company From Redmond set the project management world back decades?

They named their product Microsoft Project when it should have been Microsoft Tasks.

This marketing coup has has a profound impact on the business world, because many people now think that a project plan is a file with .mpp extension. The focus on Task Management at the expense of Risk Management has profound implications on the way projects are planned and executed. However, it’s Microsoft’s implicit market dominance, not some evil conspiratorial plot, that has inadvertently led the world astray.

Let me give you a quick, hypothetical example. Let’s say that Wal-Mart grew to the point where they were responsible for 90% of all retail business. In this world, Wal-Mart isn’t a place to shop, it’s the place to shop. When people think “store”, or “shopping”, they equate it with Wal-Mart. In fact, a majority of people have never seen a store that wasn’t a Wal-Mart.

Given this virtual monopoly, Wal-Mart then goes and builds out a very successful private label line of products. Lots of people shampoo with with WM CleanHair, kill insects with WM BugZap, etc.

Unfortunately, when they release their new private label wood stain, they call it WM WoodRefinish. Their market dominance has most people equating the job of furniture refinishing with the use of the WoodRefinish product. Heck, lots of people buy the product, and it turns their wood table into a slightly darker wood table. Success-amundo in their eyes.

Now you have lots of people who think that refinishing a piece of wood furniture is a matter of using a bottle of WM WoodRefinish. They don’t realize at first that stripping, sanding and surface prepping are the important parts of a good refinishing job. Maybe that’s why over 80% of all furniture refinishing jobs seem to take longer and yield poorer quality than expected.

But it’s not the fault of the WM WoodRefinish product. It’s perfectly good wood stain. Plus, the focus groups and marketing folks thought that “WoodRefinish” was a good name for the product.

The catastrophic failure lies in the false perception of the consumer that “applying stain” == “refinishing wood”.

Which brings us back to my central argument: Project management is not about task management, it is about risk management. Using the above analogy, the Gantt chart is the wood stain, but dependency analysis and risk management is the sanding and stripping. They are the time-consuming, labor-intensive precursors to a realistic, good looking Gantt chart.

This is why ProjectPipe is Risk-based, rather than Task-based. It intentionally isn’t centered around building Gantt charts, instead integrating with MS Project for Gantt chart creation.

Rather, ProjectPipe focuses on helping you build links and dependencies among your requirements, issues, tasks, etc. Once you understand how everything fits together, you will have a much better sense for the real tasks that you need to execute and the milestones that demonstrate real progress.

Using a risk-driven, dependency-centric approach, your task list and risk list probably won’t be perfect out-of-the-gate, but they won’t be arbitrary either.

Or, you could just just bang out a list of tasks, guesstimate their duration, wire up their finish and start dates, generate a pretty picture of cascading rectangles, then kick back and call it a day.

It’s up to you.

Don Dodge has an interesting analysis of Ray Ozzie’s recent Tech•Ed speech.

I think that there will be four key drivers of this movement back to the client/server world, none of which involve dusting off your old PowerBuilder books (not that there’s anything wrong with that):

1. Tools like the iTunes Music Store and (our very own) ProjectPipe.com will leverage and blend web technologies and existing desktop infrastructure, so that the underlying, infrastructure-spanning solution “just works”.
2. A platform for desktop-level, consumer-friendly “mashup”-type applications, that glue together RSS feeds, web services, and local data in interesting and useful ways. This will probably be some sort of Firefox extension.
3. Microsoft Live, and the ecosystem that springs up around it.
4. The movement toward desktop web applications. I think that two factors will drive this:
• The continued growth of rapid web dev frameworks, such as TurboGears and Ruby on Rails, which increases the supply-side (i.e. developers, ISVs) opportunity cost of not using one of these frameworks when building an application.
• The maturity and growing popularity of embedded databases such as Sqlite, which considerably simplifies the deployment footprint for such applications.

Don states that “The seamless, blended, client-server-services approach makes intuitive sense.” I couldn’t agree more. This was one of the core problems that we set out to solve in ProjectPipe, since so much project activity occurs on the desktop, yet so much collaboration occurs over the Internet.

We’ve referred to this blend of “Thin Client” (web) and “Thick Client” (client/server) as our Right Client Architecture, where we let the user pick the right tool for the job, and we figure out how to do the integration. For a real-world example, read about how ProjectPipe integrates with MS Project and Excel.

Evidently, Scientists Have Identified Basic Principles of Communications. The theory goes that even though you read/listen one word at a time, your brain builds out a hierarchical tree of concepts, based upon its ability to group and arrange words and thoughts.

If you are at all a fan of O’Reilly’s Mind Hacks book, you’ll find the article interesting.

In the context of that article, here are two key reasons why ProjectPipe makes project data management easier:

• Everything in ProjectPipe can be managed as an outline. If your brain ultimately manages inbound communication as a hierarchy, then we’re saving the ol’ noggin a bit of work by setting up a tree-like hierarchy for your data in the first place
• Everything in ProjectPipe can be categorized with Tags. Tagging provides multi-dimensional data management without all the scary data modeling lingo. This is real useful for those cases where one or more pieces of data crosscut a number of discrete topical hierarchies in the larger, multidimensional “web of ideas”

While IANAPOLR (I am not a Physicist or Language Researcher), I’ll go out on a limb and suggest that presenting non-trivial information as an outline or hierarchy in the first place saves a great deal of the language parsing and structural encoding effort relative to the same information being presented in prose or a flat list.

In other words, organization accelerates cognition.

Hi folks. Please pardon the recent radio silence here. We have a couple of exciting things going on. First and foremost, we are in the process of a pretty significant overhaul of the ProjectPipe user interface, which we will be rolling out in April.

Our push in the initial release was to make the underlying engine rock solid, with the expectation that our users would help us identify usability shortcomings, and we’d gradually refine the user interface. Thank you to everyone who gave us feedback in the last couple of months, good and bad. Especially the bad.

We’re focusing our energies on making the “new user experience” intuitive and productive, while making sure the UI doesn’t hinder the Power User that knows what they’re doing. We’ve cut out a great deal of visual clutter in the process. The new screens “feel” like they should have been there all along.

One of the main Lessons Learned from our initial release is this:

Don’t build your application for Power Users that you don’t yet have.

One of the core principles that we hold is that “You know more about the needs of your project than we as a software vendor do”. To that end, we’ve made pretty much all of the content in ProjectPipe configurable. In hindsight, we strove to make ProjectPipe simple, but there are a couple of cases where the original UI didn’t strike the right balance between out-of-the-box intuitiveness and Power User configurability.

We use ProjectPipe every day, and as author/users, we didn’t pick up on some of the little things (and one or two bigger things ) that could stall the forward progress of a brand new user. Since we know what the app does, we see past these issues and can focus on the work at hand. It’s the classic case of being too close to the problem.

As we’ve been going through this redesign, the “new user experience” is the basis for all decisions that we make. This approach is paying dividends. Big time.

I’ll keep you posted as we approach the rollout of this next major release. In closing, to any aspiring Micro-ISVs out there, remember: If the core functionality of your application isn’t blatantly obvious out-of-the-box, new users may not stick around to become Power Users.

]]>

Hats off to the folks at 37signals for the Business Week cover story on 3/27. (From Signal vs. Noise.)

Jason and company at 37signals proved out the model that a small team can make a serious run at the hosted application space.

We don’t really see ProjectPipe competing with 37signals’ Basecamp. ProjectPipe and Basecamp are very different in terms of product vision and features, even though they’re both hosted project management applications.

(If you’re new to ProjectPipe, check out our ProjectPipe In Under Two Minutes video for a rapid-fire tour through our key features.)

Oddly enough, I met with a prospective customer last week that ended up choosing Basecamp over ProjectPipe for a startup that he is working on. The primary reason that he cited was that ProjectPipe seemed a bit too structured and process-centric for the 3-4 person team, whereas Basecamp seemed to “feel” more flexible.

We built ProjectPipe’s Project Management Trifecta process abstraction to minimize process-based overhead while still being able to pass muster with the Project Management Office (PMO) at the typical large company.

Therefore, the default configuration of ProjectPipe ships with the minimal set of suggested Documents in the process pages. We have built-in templates for a bunch of other documents, but they aren’t suggested in the default process content.

Needless to say, it took me a bit by surprise that even our minimal default set of documents and artifacts still seemed “too ISO 9000″ for said customer. This is a great example of the value of real user feedback early in the game.

We’re working on a preliminary set of “starter configurations” that you can use to expedite the setup of your project. This is built atop the code that we’ve been using for some time to do our in-person demos. This lets us instantly configure a demo to resonate with a prospective customer’s typical project (.NET, J2EE, etc.).

In the interim, if you’re evaluating ProjectPipe and it seems too structured (or not structured enough, for that matter) , please drop us a line at support@botonomy.com. We’ll be happy to show you how easy it is to customize any or all of the content to meet your needs.

]]>

We just posted a new video, ProjectPipe in Under 2 Minutes.

Check it out. It’s largely comprised of the best “action sequences” from the ProjectPipe 101 video.

We’ve just released the transcript to the ProjectPipe 101: Concepts and Features video.

I’m sure that I turned away some potential viewers by mentioning up front that it is 20 minutes long. That’s a huge time investment for most of us. But then again, I’m a big fan of truth in advertising

If you’re pressed for time, I’d take a look at the transcript first. It should give you a good sense of what the video covers. The transcript also has the start times for each topic, so that you can jump around from topic-to-topic if you prefer.

Also, the video is encoded for progressive download in Quicktime. Even though it’s a large file, it starts playing almost immediately.

We wanted to get a single “umbrella” video published that covered the breadth of what ProjectPipe has to offer. I tried to walk through the subject matter at the cadence and level that I’d cover in a one-on-one meeting over coffee at Starbucks: More detail than a multi-person conference room sales call, but less detail than a formal training video would provide.

Going forward, we’ll be producing much more topic-focused content in much smaller chunks.

]]>

We’ve posted our first screencast. It is titled ProjectPipe 101: Concepts and Features.

The video is in Quicktime format.

Running just over 20 minutes, it covers most of the key ProjectPipe features, including:

• Tagging Support
• MS Project and Excel Integration
• Dependency Visualization
• Integrated Change Management (between Subversion and the Issues List)
• RSS
• Role-based Security
• Configurable Templated Content

Check it out. If the video piques your interest, we have Free and Paid accounts available, and you can be up and running in less than a minute.