I am starting a new category of essay: Project Management with The Core. Besides family issues, this is the most requested area when clients ask for advice.

The Core supports skepticism. By “skepticism” I mean the questioning of conventional thinking and assumptions. This is very different from cynicism. When I say cynicism I mean the criticism or sabotage of positive endeavor because of a lack of hope and faith. Skepticism is identified by its curiosity and experimentation whereas cynicism is typified by a lack of results and a lack of support for those who do get results.

I was lucky enough to get a manager very early in my working career who was skeptical of conventional program management practices. She supported me in shipping quality products on time by doing what made sense instead of what I was “supposed” to do. When I met Jim, he and I had a similar skepticism for such things and we taught each other what we had discovered in the meantime.

Conventional project management dogma goes something like this:

*Define your goal: time, scope and resources

*Specify your project: the more detail, the better

*Build a schedule for your project: the more detailed the better

*Begin working on your project, adhering to the spec and the schedule

*If you fall behind in some area on the schedule and there’s nothing to be done, include this ‘slip’ in your future schedule and report it to your managers

*Keep updating the spec and the schedule as the project goes

*Ship according to schedule.

In my experience this doesn’t work well at all. You can specify until you believe you’ve thought of everything. You can work hours and hours on a Microsoft Project schedule which details every little dependency in your schedule. You can add months of “buffer” into your Project schedule. And still, you are likely to be late and burned out.

I believe in judging new ideas empirically. So, I can tell you the above doesn’t work and other methods work much better from experience. However, I also have theories about why it doesn’t work.

Team = Product

My first theory about why it doesn’t work is that it is all about bureaucracy and not about people. Creating great products on time is about creating a great team and then having it ship something. If you are spending your energy creating specs and schedules, you won’t have the time or energy to create a great team. A great team is far more important. A great team can invent the product as it goes. It can turn on a dime. It can come up with a BIG idea to bring the schedule in on time when everything seems to be working according to Murphy’s Law. The team members on a great team can cover for each other if someone gets sick or goes on vacation. They can learn new skills in real time because they are passionate about what they are working on and who they are working with. A great team can do everything that a spec and a schedule can’t. And I haven’t once seen a spec or a schedule contribute to the greatness factor of a team.

(For more on Team=Product look at SFYH)

Trust vs. Control

My second theory about why it doesn’t work is that it focuses on control, instead of trust. By “control,” I mean the neurotic type of control wherein we wish that humans were more robot-like and life was more predictable. The interesting thing about desiring this type of control is that it results in less actual control. Desiring control is self-destructive.

One of the new lessons of BootCamp (thank you leaders of Halliburton Energy Services!) is that it is far more effective to replace control with trust. If you put your energy into creating alignment with your team members so that you can build trust, then you can achieve great results. When you can trust that your team members are aligned with you, you don’t have to write every detail down. You don’t have to plan every detail before you implement. You don’t have to have hours-long meetings with too many people in them. You don’t have to “control” what everyone is doing at all times. Because you have alignment and trust.

The Core Project Management

In my experience, the following does work. Every time. If you do this, it will work. You and your team will be heroes.

*Make sure your team is booted (If you believe you are blocked on this step, proceed anyway. You will encounter much more suffering without a boot but you can still ship on time.)

*Get a shared vision for your team’s work (If you believe you can’t do this, proceed and you will probably succeed anyway. You will be missing a level of greatness that comes with shared long term vision, but you can ship something near-term on time.)

*Get a shared vision for what the message of your next version will be

*Pick a date to ship it that aligns with what you and your customers want

*Make a prioritized set of features (aligned with your customers) and begin work on #1, then #2, etc.

*Maintain alignment with your team(I will provide many tools to do this in later essays)

*Practice shipping with interim milestones

*Stop creating with enough time to stabilize your version (usually about 2 months).

*Ship the version on the date you set at the beginning.

(For more on this algorithm read the IDP in SFYH or the BootCamp Manual)