So here’s a quick blog on project planning and the two key questions that
I’ve found consistently improve your results, regardless of how you
approach project planning.  Let  me know what you think.

Two questions that improve any project planning effort.

1. The first question is simply this:  “How much face validity does
the plan have,  to you… to others… in representing the key steps
needed to reach the outcome?”  This question is generally applicable,
but creates  the most  value when heading into uncharted areas,
creating innovation, etc.

Face validity is the sense you get when looking at a plan, that it
addresses the needed steps.  It makes sense.  If you had to bet your
lunch on it… you would take the bet. 

Here’s the real secret to face validity.  It’s outcome based. 
The plan looks like it will realistically get you to the outcome. 

You might be surprised at how many people get lost when creating
a plan, want to make sure they include everything and lose the focus on
“what’s the outcome” and “are we doing what’s needed to get us there.” 
There really is no other basis for plan validity.  It’s what separates
forms and lists from a real plan.

2.  Here’s the second question: “Is it (the plan) working?” 

That conveys two things, which can be very difficult to get.
It conveys that you keep the plan open to adjustments.  Maybe I
should better write that as you keep hammering on and reshaping
the plan based on what happens mid-stream.

It also conveys that you’re getting data, updates, results, feedback
in a timely manner that let’s you respond to that question based upon
current data… nothing else.

You see I think most people mistakenly believe that project planning
is limited to the first part of a project.  Like there’s some point at which
you finish the plan, and then you just execute it from there.  I think
that’s a big mistake, at least it sure is on most of my projects.  I can’t
remember a single major project in the last 10 years that worked out
exactly according to the initial plan. 

If you don’t update the plan, it quickly becomes outdated and marginalized,
or drags the entire project management process down because  efforts
are aligned with an outdated plan that doesn’t reflect current realities well.

What if project planning keeps going until the project is complete and
you’ve done your “lessons learned” review?  For me, project planning
starts with a definition of outcomes, schedule and resources, but
continues throughout the life cycle of the project with a continual
reference to that key question – Is the plan working?

Bottom Line:
Project planning is mistakenly thought of as a phase at the front end
of projects.  I think it goes throughout the life cycle of the project and
is best shaped by two ongoing questions:
1. Does the plan have validity, does it make sense, will what’s included, 
what’s focused upon, clearly get us to the outcome?
2. Is the plan working, have you checked, based upon what data?

Separate yourself from the crowd - keep it real and keep it current.

Here’s how the pieces go together for me, in 4 simple statements:

1. Project management is nothing more than being accountable to work smart.
2. Working Smart is working in a way that’s accountable and respectful to people and the Outcome.
3. Management’s biggest challenge is holding others accountable to work smart. (Biggest failure is more accurate)
4. The biggest frustrations at work come from working with people who aren’t accountable to or respectful of persons, or being subjected to work processes that don’t add value to the process of reaching the Outcome.

Think about that first phrase and let me know your reactions. Here’s a couple of ways it gets worded in my brain.

Project planning, updates, planning the work and working the plan, focusing on priorities, coordinating with others, collaborating with others, being sensitive to time and dollars and quality… they’re all just characteristics of working smart and being accountable to people and the Outcome.

How about dealing with stakeholders or resource allocation? It’s all part of being accountable to and respectful of people and their time and needs.

How about using technology or setting priorities, or managing time? It’s all part of being accountable to the Outcome. Accountable to use the best tools and prioritize your resources to reach the outcomes that are most important. You only need to plan if it helps you reach the outcome. You only need to estimate time and report on progress if it helps you and other’s deliver on time, within budget and at the quality level needed.

Bottom Line:
Project management boils down to a single concept for me… accountably working smart. And working smart reduces to a “head’s up” manner of working that is sensitive to people and the Outcome, and making the adjustments to reach both within your time and resources.

Links:

Working Smart – 3 Keys

Working Smart – Habit & Comfort

Work Smart Software

I noticed she didn’t say the software should flexibly adapt to
those differing needs or specific outcomes.  She did
list a couple of suggested programs at the end of her article,
but they aren’t really flexible software designs.  Maybe project
management software isn’t supposed to be flexible? 

It got me thinking, but first let me cover a bit more of what she said.

She interviewed “nine nonprofit project managers (asking) what
project-management software meant to them, and what software
they were using to manage their projects.” She went on to write,

“Their answers varied, but when we boiled it down, project managers
were using software to support six different types of
project-management functions.”
1. Planning Projects
2. Managing Tasks
3. Sharing and Collaborating on Documents
4. Sharing calendars and contact lists
5. Managing Issues or Bugs
6. Tracking Time

Her interviewees were apparently defining project management based
upon the outcome they needed or used it for.  Sort of reminds me of
the story I learned when I was a kid, about the blind men trying to
define what an elephant was.  Each of them making a definitive
statement based upon their own experience or requirements.

When I step back and look at it, I have a couple of different thoughts.

1. First of all, although she defines it as six different types of functions,
I only see broadly three:
    1. A planning function, (create a plan to use in a variety of ways)
    2. Track activity on the plan (tasks) and all the activity to address variances (issues).
    3. Sharing information (calendars, documents, contact lists, updates).

2. Here’s a second thing I find interesting about the study.  She interviewed
project managers to gather her information on this area.  They apparently
didn’t share a common definition of project management.  In fact,
reading between the lines, project managers are defining project
management based upon their outcome needs, not the overall scope of
activities included in structuring work around projects. 

3. As you look at her 6 categories, or my 3 categories, doesn’t it strike
you that most people at work need to do all of either list at some point
on any given day?  Does that mean everyone is a project manager?

Doesn’t everyone, from the admin to the CEO, have to manage tasks,
do some planning, track time, manage issues, work from shared
documents?

Project management starts looking really diffuse, or maybe pervasive?
Or maybe project management, defined as something that “project
managers” do, has lost its definitive edges as it gets applied in the
work place, because everyone who manages information as part
of their job is involved at a general level in project management - 
back to that fuzzy definition. 

The term project management for most of us, starts looking
like another name for working in the information age.  Is that
project management?  Does the term need to be redefined or reworded,
or only used with a qualifier?

If project management in the general sense roughly approximates something
that most people do as they work in the information age, this has tremendous
implications for how flexible “project management” software has to be.

Project management in this general sense, stands out in contrast
to somethingthat engineers do as they design a multi-month, multi-person,
multi-task, path to an outcome.

Bottom Line:

So if you are looking at project management software, be very
careful about your definition and desired outcomes.  If your
scope of work defined as projects is very broad, you’re going to need
a very flexible software tool that you will want to use for most or all of
Laura’s 6 categories – if not more.

If your defined project management outcomes are very specific, the tool to
help you reach that will typically be non-flexibly designed.  Why?
Typically it has to be to reach that type of outcome, e.g. the more the
project management software looks like it wears an engineering hat, the
more rigid rules imposed for how information is entered, modified and output.

Links:

 Flexible Project Management Software – The Design Factor (1 of 2)

 Flexible Project Management Software – The Design Factor (2 of 2)

Adaptive Design and Project Management Software Flexibility

Flexible Project Management Software – All-in-One Solution

PC Magazine – Project Management Software for the Rest of Us

Microsoft Project Alternative

Well actually it does, and in fact the design of the project management
software isn’t exactly neutral in what it favors, as research in the last
few years is pointing out.

Let me go over one study with you, and then talk about implications.

The study I’m referring to is “The effect of decision style on the use
of a project management tool: an empirical laboratory study” found at
the database for advances in INformation Systems – Spring 2005 (Vol. 36, No2).

In summary, when studying 52 project managers all using Microsoft Project,
they found that left brain dominant (described as directive and analytical)
project managers, as contrasted with right brain dominant managers:
    1. Complete project plans using MS Project quicker,
    2. Completed project plans more accurately than their counterparts, and
    3. Were more accurately able to use the tool to analyze effects of changes.

One of the implications from the study is that current project management
software tools, such as Microsoft Project, are not as well suited to right brain
dominant managers.  Julian Mendoza in a recent blog, points out that it isn’t
just Microsoft Project, but the greater project management community as
represented by PMBOK, over-emphasize left brain or linear approaches to
planning and problem solving.

So is it the design of project management software that skews it to a left
brain view of the world?  It certainly seems that project management
software is not flexibly designed to adapt across left vs right brain
dominance.

Flexibility and design seem to hinge on the assumptions underlying what
is defined as the “preferred path to the solution.”  E.g. current project
management software emphasizes connecting events with durations and
cost factors, summing the totals (durations) and defining the end point
based upon those summations. 

Scheduling is king.  Additionally Agile based project management solutions
also focus on the schedule end date, but emphasize deriving that in large
part based upon the burn-down trend, e.g. how fast are we completing tasks
and how many are left?

Actually I think that the design of project management software not only
emphasizes left brain assumptions and strengths, but as it gets applied to a
variety of types of projects often looses value, while increasing the difficulty
of work – because of it’s lack of flexibility.

Bottom Line:
Let me leave you with a couple of things to chew on:

1.  Fox and Spence’s research suggests left brain managers “significantly out
perform” right brain managers using current project management
(MS Project) tools.

2.  I’m suggesting that most project management software is designed with
a lack of flexibility and does not readily adapt to left vs right brain dominant
managers, and in fact is best suited to left brain operations.

3. As business works at being more efficient, project management software is
being more broadly applied and inevitably handed to more individuals who
are not left brained, and for whom the emphasis upon planning and scheduling
does not fit the scope of work.  E.g. project management software is getting
applied to a wide range of ad-hoc tasks and challenges, not just large scale
construction and manufacturing problems.

4. I think left vs right brained individuals organize information and ask
very different questions in the pursuit of managing projects.  By-the-way,
there are several tests out there to help you determine which side of the
brain you use the most, but my favorite way is to look at your garage. 

If your garage is neatly ordered, everything in it’s place, more or less - 
you’re likely to be left brained.  If it’s a place where you stash things, and
you know where to find stuff based upon your memory of where you last
left it, you’re more likely right.  Or hopefully you use both sides, but we
all have a preference.  Garages don’t lie.:0

Links:

Flexible Project Management Software – the Design Factor (1 of 2)

Flexible Project Management Software – the Design Factor (2 of 2)

Flexible Project Management Software – That Wraps Around Your Preferred Style

Before I do, just a bit of recap. In the first blog we looked
at choosing a software package that matched the complexity
profile of the projects you work on.

The fit between Design and Scope of Work determines value delivered.

Put another way, match the design of the software to the
type of work you do.  E.g. You get the most value when you
only use as complex (powerful) of a tool as is required.  Extra
power (increasing complexity) always requires more time,
effort and cost to use. Or hopefully, you find a flexible
project management software that is designed to adjust
to your varying needs.

So let’s get to this study and what it means in terms of design.

Here’s the second hidden factor about design.  It’s
underscored by a research study by Fox in 1999
“Do the Features Support the Functions?“.

In a nutshell it’s this:

1. Project Managers (PMs) buy based upon the complexity
(accumulation of bells and whistles) of the design…
2. PMs use based upon the simplicity of the design,
3. At the end of the day, PMs fail to leverage information well.

Let me review just 3 of the findings from this survey of over
1,000 project managers that underscore what I just wrote:

1. First of all, in 1999 MS Project was the top ranked project
management tool purchased, but it “received the lowest
overall satisfaction rating” of the 10 most frequently used
(project management) tools. I’ll review what this uncovers
in just a minute, but first here’s the other two findings you
should know about.

2. MS Project was the most frequently used tool (59% of the
time), but with regard to supporting (the entire range of)
project management functions as a whole.  MS Word…
actually received a higher overall rating than MS Project.

3. Although MS Project is the most widely used project
management tool available today, the “second most widely
used project management tool (is) MS Excel – not a traditional,
project managment-specific tool.”  With MS Word not far behind.

I’m citing that study not to bang on MS Project, but to point you
to something more important.  If you look carefully at the
results you realize that the 1st finding is actually reinforcing
what we discussed in the first blog.

That is, when it comes to project management tools we tend
to overbuy.  We choose something more complex then we need.
We base our decision on some other driver than “fit”, and then
are not satisfied.

Yes, you could point out that the study indicates MS Project fails
to deliver to user’s satisfaction.  But I think this is only partly
related to it’s functionality and interface.  I think it is more
directly related to why people buy MS Project or any other
leading project management tool (ex.”it’s the safe choice -
it’s the industry standard”), and then find it not well suited to
their needs and purposes.  Eg. We buy based upon power
and comfort, not practicality.

The 2nd and 3rd findings point out something dramatic as well.
Here it is in a nutshell – Most of us gravitate to something
simple and flexible for typical project management work.
Simple tools are preferred over something complex and
powerful as a preferred project management tool of choice
when it comes down to day-to-day use.

By simple, I mean it’s easier to get information in and out.
From free form (word processor, blank sheet) to simple rows
and columns, both Word and Excel don’t require much
learning curve or advanced planning to begin typing.

But before you hug your trusty spreadsheet, let me point out
one very big flaw that wasn’t discussed in the 1999 report.

Big Flaw:
If you look closer at the design factor, you realize that most
of the project managers are choosing simple tools that have
a very low ability to leverage information.

That’s still going on today.

I see this over and over in the US.  People are reluctant (that’s a
nice word) to invest the energy to input  project management
information into structures that will support leveraging the
information for easy access and re-purpose across the team,
across the organization, across time.

It’s 9 years after this study, and I think the primary findings would
still stand up, except that it looks like most people would
simply add MS Outlook as the other common project management
tool in use.  But, neither Outlook, Excel or Word leverage information
well – e.g. for you to see what I’ve written, I have to copy, attach,
print, save, etc… none of this is available to you across any
task or project within two clicks.  We haven’t progressed much!

One thing that has changed since 1999, and that is that PMs are
much more frequently using web-based project management
tools.

One quick closing comment about web-based and design.
If you look at most web-based project management tools
today you’ll find that they leverage information better, but
due to the defined form structure are not very flexible.
E.g. you can’t modify the layout to suit your business needs.
Stay inside the box and you’ll be just fine.  Buyer beware that
you won’t grow out of the box confines.

Bottom line:

1. In the first blog we looked at choosing a software package that matched the
complexity profile of the projects you work on.

2. The fit between Design and Scope of Work determines value delivered.

3.  Most people need flexibility, not only for the range of projects they are
managing, but also given the range of people’s needs working on the project.

4. If you are to effectively extend the value of project management to broader
usage, the entry usage level needs to be simple.

5. Simplicity is not all that it is cracked up to be.  You need flexibility that
includes simplicity, but it has to leverage information, otherwise simplicity
on the front end creates more work, more emails, more reports, more time
wasted on the back end.

6. PMs buy based upon the complexity (accumulation of bells and whistles)
of the design… PMs use based upon the simplicity of the design,and at the
end of the day PMs fail to leverage information well.

Recommendations:

1.  Be careful what you choose when it comes to project management software,
you may have to live with or work around (compensate for) it for a long time.

2. To get the most value, match the design of the project management software
to the type of work you do, with an eye toward leveraging information and
flexibility built into the design.

Links:

Microsoft Project Alternative

Time is short,  let’s take a look at the hidden Design factor in this
and the subsequent blog, and how it impacts you.

Before we get started on design, a brief baseline. Project
management software represents both a promise and a
challenge. The promise looks something like, “if you use this
tool, you’ll be on track, on time, within budget,
complete what you set out to do, etc…”

But it turns out that the (reality) challenge of completing the
project is bigger than the promise, given all the failed or over-run
projects that occur – that presumably were to be avoided by
using project management software.

I’m sure you’re aware of that – and if not, it’s easy to research
via Google.

So here’s the first thing to get about project management
software design – this directly effects your time and dollars.

1. Project management software comes in all
sorts of design configurations, from simple to complex.
Theoretically you should choose no more complexity than
is required to complete your job, as increasing complexity
always requires more time, effort and cost to use.

If project management software was equivalent to tools for
digging in the dirt, you would probably agree that they range
in complexity from shovels to large earth moving equipment.
So, common sense would suggest that you pick the tool
that’s right for the job… and only spend as much money
as you need to.  Right?

But, here’s what most people don’t think about. What does
your project mix look like on the job? What’s the % of time
spent working simple vs complex projects? E.g. if only 5%
of your time or resources is spent on complex projects,
you wouldn’t buy a complex software with all sorts of bells
and whistles… just because it was the biggest or
market leader… or would you?

Take one more look at this. What if you looked at the
needs of the people using the project management software.
What % of your people working on projects need something simple,
versus complex or high powered? I’m betting the % on both is
a 10/90 split or higher – with 10% or less going to high powered
requirements.

Well, it turns out actually lots of people/organizations buy more than
they need, or worse… can sustain. This is an easy one to
trip over, but why?

Why? Because it has an immediate sense of comfort.
A protection against the distressing discovery that they have
purchased something that will “let them down” or that other
people can criticize as under performing. It avoids the dreaded,
“Why did you buy that software?” challenge. Reminds me of
that old phrase, “no one ever gets fired for buying IBM.”

Design factor, as it effects the simplicity vs complex dimension,
can trip you up in two ways.
1. Over Buy: You can protect yourself against not being sure about how
much you need and just over-buy, get something bigger than
you need… just in case (and then struggle with a low % of people mastering
it’s complexity).

2. Under Buy: You can also buy something “simple.”   But again, if you don’t
accurately assess your needs, it’s easy to trip and inaccurately�
determine if its simple design has enough flexibility and capacity
built into it to avoid limiting you and your team going forward.

Here’s the bottom line:

Most of us need a flexible project management software.
In fact we need it much more than we realize – not only to
match up well against the range of projects we are managing,
but also given the range of people’s need working on the project.

One tool that can be work simply when that’s all that is
required, and yet have the power built in when we need it.

But, an important hidden gotcha, is that along with flexilibility,
project management tools also need to leverage
information really well. That’s an issue, especially when you
begin looking at simple tools, really all of them.

We’ll dive into that on the next blog. See you there.

I think the whole project management discussion and process
would do much better if it learned from music.

That probably sounds strange, but let me explain.  I’ve had the
opportunity in my life to play classical music, to play rock and roll
at clubs and parties and with Elvis impersonators, and jazz with
people like Benny Goodman.

They all are different styles of music, they represent certain differences
and certain parallels in getting from the start to the end of a piece.
They all have a place, serve a function, have a following.  You wouldn’t
typically say one is right and one is wrong.

If you compared music to project management, you might say both
are a way of organizing people and their actions to generate certain
outputs.  Yikes that sounds detached.

What I’m getting at is this:
Playing music is roughly equivalent to project managment.

When playing classical music, you play what’s written, so that dozen’s of
people can all produce and finish largely an exact copy of what was
originally penned.  Very structured.  Very defined.  It is akin to one form
of project management as perhaps best applied to producing known
outcomes.

In playing the blues, you usually are working over a 12 bar chord
progression, with a particular use of thirds and a base pattern that
gives it that unmistakeable “blues” sound and feel.  Much less exact
or prescribed than classical, yet it has a defined sequence and feel
that has to be created for it to sound “right” to the listeners.  Again,
it represents a different form of project management.  One that allows
more latitude, but still moves through various phases or gates.

When it comes to playing jazz, there’s lots of room for freedom of
expression, interpretation, adaptation, how long you play the song
(e.g. how many repeats), what exact chords you play from verse to
verse, and for adapting to the unexpected…

Jazz is still music, the players still work within a structure, they still start
and stop, they still produce an intended outcome.  But if described in project
management terms, it’s a very different model, perhaps more like Agile
than PMBOK (classical).

Bottom Line:
Project management and playing music have some strong parallels, and
my perspective is thatproject management would benefit from embracing
the fact that there are different appropriate forms of project management,
just as there are different forms of music.

Part of the differentiator seems to be how much the project is to be a
replication of defined, known requirements, versus an improvised creation
with a roughly defined outcome (e.g. let’s play Stella by Starlight in 3/4
instead of 4/4, key of G, you take the first chorus and we’ll finish by playing
it one moretime through from the top).

Maybe the less we know the exact outcome and all the obstacles we will
have to overcome to reach that outcome, the more project management
needs to move from a classical to blues, to jazz orientation.

Links:

Does Project Management Inaccurately Represent Work

Flexible Project Management Software

I think not, at least in terms of how the majority of our time is structured.  In fact, I believe a todo or task management maturity model might better suit most organizations. There is a lot of excellent material written about project management maturity models, addressing the degree to which or how complete, how systematic and how comprehensively organizations utilize a project management system to organize and complete their work.

However, if you pulled the curtain back on most organizations, aside from formal schedule based production work, like you might see in construction or a production environment, the project management maturity model doesn’t seem to match up to how work gets organized 95% of the time.  Often it sounds like another universe.

Why? First of all I don’t think most people’s work gets organized into projects.  I think for most people it gets organized into a series of habits and tasks… You know, stuff you need to do as part of the job, which if it you’ve been working it very long, you know from experience (e.g. it’s a list in your head).  Secondly it’s stuff that comes in via various “channels”, e.g. email, meeting requests, phone calls, and deadlines of one sort or another, which may be written down somewhere or in multiple places, or it may be represented by folders stacked on your desktop, a collection of phone messages… maybe post-it notes stuck to your monitor.  Note that referencing a project plan is probably not one of the predominant input channels for most people.

Let’s face it, most of us spend relatively little time working a project plan, mostly our day would be better described or represented by a series of written and unwritten todos.

After facing the reality that most of work is organized around todos, not project plans and the supporting work breakdown or task structure, something else strikes me.    For the most part, we are not plan driven, we are “prompt” driven.  By that I mean we rely upon prompts (not a project plan) to get to the next todo.  The basic prompts we all use are:

• A calendar (if its not in my calendar it doesn’t get done – some might say),
• Email, (checking your inbox)
• Visual reminders (stacked papers, stacked folders, a white board),
• Verbal reminders (admins, phone calls, meeting communication),
• Memory (internal reminders) and
• Todo lists – whether in fragments or all in one place.

My observations are that most people we work with not only infrequently reference a project plan, but they also would generate more immediate benefits from improving on todo management than project management.  Better management of todos across an organization is the prime area to improve on for a majority of organizations, if not a precursor to improved project management.

Maybe instead of project management maturity model, we need to focus on a maturity model for todo management, e.g. to generate a “maturity of systematic approach” to the structure for managing todos to result in improved success rate at delivering on objectives, budgets and timelines. Here’s a couple of initial suggestions about what mature Todo Management system might look like:

1. Todos’ are visible and leveraged by tracking in one system.  Todos represent a fundamental work tracking system that needs to be formalized, not scattered across various systems.

2. The formal system provides a prompting for delivery of todo based requests and commitments (within a calendar, within a list, auditory and email prompts).

3. Most people profit from attaching todos to topical based outlines, as that seems to help secure memory associations and help avoid details slipping through the cracks.

4. Most people need a follow-up system when assigning todos to others, e.g. a vehicle for getting feedback on the request they made, without having to initiate the follow-up themselves.

5. Incoming email, including attachments, needs to be easily parsed and reformulated into todos that are frequently embedded in the content.

Un-abashed Plug.  If you are interested in improving todo and task management at your work place, we don’t think there is a better system for managing todos, attaching them to a concept based outline of departments and project listings, and assigning and tracking them across people than ManagePro.  In the upcoming next release we even provide a performance measurement based on each individuals’ ability to complete todos each day.

Bottom Line: The maturity of an organization’s system and process for managing todos may better predict an organized work flow and positive outcomes than a project management maturity model. Does it for the organization you work in?