More unsolicited advice on running projects…this time from Top Ten Lists.

The Top Ten Keys to Making Projects Successful. Who knows what (if any) empirical evidence was used for selecting the top ten of the 20 or 30 best actions one can take. In any case, you might discuss the list at your next team meeting to assess what you might do differently.

I promised to share my questions for the panelists with you. I've decided to take a practical approach. We'll be investigating getting a lean project delivery approach started and keeping it going. Please take a look at these questions.

• How did you get interested in lean?
• What did it take to get started?
• [Follow-up question from audience]
• What benefits accrued?
• What most surprised you?
• [Follow-up question from audience]
• What obstacles did you encounter?
• What three lessons can you share?
• [Follow-up question from audience]
• What makes lean different from other improvement initiatives?
• What are you working on now?
• [Follow-up question from audience]

What else would you like to know? What would make the conversation interesting? Please leave your thoughts as comments to this Reforming Project Management posting.

Just give me the facts. Have you said that? I have. What is this about?

We operate with the illusion that we can be objective. Illusion? Yes. I've often heard people say, "If two people have the same facts they will agree." This is absolutely not true. We have hung juries to prove that. So, why do we continue to cling to this illusion of objectivity on our projects?

Our attachment to facts is associated with our predisposition on projects to operate in a predictive deterministic mode. We (falsely) think that with enough facts to do our planning we will put the right plans in place. In so doing we can determine exactly what must be done to succeed. After that it's just execution.

A focus on the facts misses what is most-valued on projects. What is that? It is the informed and seasoned judgement (opinions) that give rise to course-correcting or adjusting actions. Of course, we want to ground those assessments in facts. However, waiting for the facts can keep us from taking action at a time that will make the most difference to the project results. We value the seasoned professionals not for what they know, but for their uncanniness — that ability to make those course-correcting assessments based only on their inklings.

We must face the facticity of projects: we don't have facts about the future. Projects are always about the future. In the face of project uncertainty story-telling gives confidence to teams as they go about their opinion-making.

Project tools have not been designed for story-telling. The usual tools collect schedule data, cost data, resource data, contract data, and customer requirements. Schedules, budgets, plans, contracts, and requirements are at best intentions for the future. Unfortunately, we treat them as what must happen. In the face of an uncertain and unknowable future we need something else. Teams need a basis for opinion-making, for context, and for team alignment.

The p-log provides the team with a mechanism for making sense…for building confidence…and for staying in charge. How? Stay tuned.

BTW, the pundits are speaking about Google|Blogger and the business use of weblogs. Here's the latest: Puzzling Out Google's Blogger Acquisition by Chris Sherman.

Over the weekend PM World Today ran a lead story Project Weblogs by Rainer Volz in the Feb/Mar issue. They also picked up the p-log postings Tools for Business and P-Logs for Project Teams in Reforming Project Management. What's the significance? PM Forum is a highly visited independent project management website. While they don't see themselves as an alternative to the mainstream PMI, they are willing to write about what is occurring at the fringe of the practice of project management.

Take a look at the article. The author describes three characteristics of weblogs that make them suitable for project teams:

• Easy, fast, and continuous communication
• Personalisation and identification
• Automatic storage of knowledge

He argues that virtual teams must overcome physical separation. All that makes sense. But there's more too it than that. Project teams need to be in charge of their projects. They need confidence while exercising judgement. The p-log just might be the tool.

BTW, Google purchased Pyra Labs, the Blogger company. This occurs at the same time that AOL is expected to launch a blogging service for their members. What is this craze about? I'm sure we'll be reading the pundits' views any day now. In the meantime, I'll offer my out-of-the-loop view.

• Blogging tools are some of the easiest ways to keep a web-presence fresh. Websites that are fresh are read and referenced. (Some days I use AOL Instant Messenger to make my postings.)
• A micro-industry is growing to support bloggers. This community has been a mostly free (or near free)
• We all have a story to tell.
• We enjoy reading stories
• Legitimate journalists, essayists, and educators of all sorts are using the medium of a weblog to extend what they are already doing.

Weblogging has gone mainstream. Can p-logs be far behind?

Here's my Proposal for a P-Log (Project Weblog) Specification.

Why the Interest in Weblogs?
I've been curious about the role blogging could play on projects. In October I did a posting Project Klogs: Changing Paradigms on John Udell's view of weblogs for projects. Udell claimed our tools and practices don't attend to the story of the project.

Projects fail. This is the usual case. We all know this. Attempts by the PMI to address this have not succeeded. It's time for something completely different.

Why A Specification?
We've been designing and redesigning the same collaboration tools for years. Ten years ago I used an early Lotus Notes database for project management. Back then and today the collaboration environments do the same things: provide status, track issues, and discussion. We can do those things with a p-log. But there are three critical issues that need attention that haven't got attention:

1. Uncertainty - the future unfolds influenced by actions of the team and the world that is unfolding around the team. Planning is the conversation for participating in the infolding.
2. Learning - the vast majority of knowledge is tacit. Projects are one-of-a-kind opportunities to share, deepen, innovate, …
3. Mood of the team - enthusiasm beats complacency, cooperation beats (internal) competition, determination beats resignation, and wonder beats arrogance. Yet, when mood is left unaddressed we get what we get.

P-logs are about the story of the project and the team. P-logs are for the team to take charge of the conversation of the project.

What's Next?
Perhaps this is too ambitious. Perhaps nothing short of audacious ambition will get at the underlying sources of project failure. I propose we do this together. How about a project conducted with a weblog for developing the p-log? (Thanks Joe for the proposal.) In the next few days I'll write about aspects of the p-log specification. Please join in with your comments and questions, suggestions and criticisms, and offers to build and use a prototype p-log.

Weblogs, like Reforming Project Management,
have proliferated. In a popular discussion group on Scrum Development, the proposed use of daily status logs attracted some of the best postings in quite some time. Many commented on the shortcomings of collaborative environments while others spoke of the value for enhancing knowledge-sharing, collaboration, and improved coordination.

In November 2002, Network World Fusion hosted a debate of the legitimacy of weblogs as business tools. Bill Keaggy argued favorably.

Using Weblogs in your business environment can increase employee communication and knowledge, save time and resources, and build reputation and confidence.

A blog can keep everyone up to date on projects without clogging in-boxes. It also can provide an archive of mistakes and milestones that could be shared with other teams undertaking similar projects.

Speaking for the other side was Mark Hurst.

There's nothing inherent in blog technology that will transform a business. A page of online posts, sorted reverse chronologically, just doesn't by itself change a corporation. If anything, the blog is inherently less effective than a more popular tool that companies have used for years: the e-mail newsletter.

One reader commented:

…the blog becomes a true knowledge management system. It's an archive of all the news and information that's relevant to them, which is searchable and sortable - including their comments and annotations.

When companies set up their own internal blogs, they need to convince people to take time from their daily work to put stuff into it.
Mike Masnick, President, Techdirt Corporate Intelligence

Or, should we really be considering a project management information system? George Sifri answered that question in December 2002 in a Builder.com article. Sifri says, "(P)roject managers often fail to deliver the types of information needed to ensure project success." Good start. Unfortunately, he adds, "(A PMIS) is able to provide upper management with adequate information about all the projects in the organization's portfolio." He offers these seven objectives for a PMIS:

• Enable the project team to identify and isolate sources of significant variances and determine the reason why a project deviated from its plan.
• Allow the project team to track the status of the work packages in order to determine the work that is completed and the work that is still pending.
• Help the project team manage project schedules by providing the basis for work package resource allocation and work timing.
• Interface and be compatible with larger legacy information systems.
• Help the project team forecast the impact of certain risks on time, costs, and quality baselines.
• Give the project team insight into what revisions to the baselines they need to implement, when they should implement these revisions, and why they are implementing these revisions.
• Integrate with the work breakdown structure (WBS), which provides the capability to report the status of the work packages throughout the project's life cycle. These reports include identification of the work package, its associated cost code and schedule, and the individual responsible for the work.

Sounds to me like Sifri supports the more structured heavy-weight approaches. The vast majority of projects lie in the middle between the unstructured use of email and the formal project management information systems. Let's explore a solution for the rest of us.

Tomorrow, look for my proposal on what a p-log should contain.

I am booked to be lead a panel of leaders who are implementing a lean approach to construction project delivery. The summit will be held March 9-11 at Amelia Island Plantation, Jacksonville, Florida. In addition to the reprieve from bitterly cold northeast weather, I am looking forward to interacting with these leaders. They have years of experience delivering projects on-time or early AND at or below budget by taking a lean approach. And they have the battle scars to show for it. One person carries the title VP of Production & Process Innovation. Another is the head architect of an integrated design-build firm. The last member is VP of Operations for the Automotive Construction Group and he's an architect.

We will be discussing issues with implementation starting with doing the first pilot to rolling out across the company. I'll share the questions I'm using to prepare the panelists next week. I'll give you another update following the event.

We've all heard the expression, "The only stupid question is the one not asked." Patrick Andrews puts his own spin on that in the article How stupid questions can lead to smart answers. Patrick is writing for technical project managers, but his comments apply more broadly. He tells us to admit our weaknesses.

When I ask for help in understanding some technological subtlety that underpins a project management decision, the experts on my team know that I trust them to explain things. They very much like being questioned as this gives them a special status, allows them to demonstrate their knowledge, and provides them with a way to contribute to the project in a novel way.

Patrick offers us 8 stupid questions to get us going. (Like I needed help)

• Why are we still using this tool?
• Can you remind me why we decided on this approach?

How much does this procedure actually cost us?

• Can anyone explain this problem to me in simple terms?
• Who’s our best person at dealing with this kind of problem?
• What does that acronym actually stand for?
• If you were in my shoes, what would you do?
• Why is your idea better than the way we usually do things?

Not to be one to leave well-enough alone I propose two additions to his list:

• Do we need to be doing this now?
• What would the customer think of this?

Leave your suggestions for dumb questions as a comment to the posting.

Patrick leaves us with this thought, The trick for effective project management is to really listen to the answers—and never ask the same "dumb" question twice. Oh no…there's that L-word again!

Here's another piece on deadlines. You'll remember Aubrey Daniels said look to the system when deadlines are missed. Tom Mochal provides a different take on a similar issue What to do when impossible project deadlines are common procedure.

A reader asked, "How do you handle a business unit's impossible deadlines?" I love Tom's answer, "Take control of your project and stop being a victim." Unfortunately, the rest of the article can be summarized as make the most of your situation.

Tom offers these prescriptions for "taking control":

• Risk management
• Issues management
• Scope management
• Proactive communication

He doesn't address the leader's and team members' moods of frustration, resignation, and detachment from the purpose of the project. Even if the above four actions could work (I doubt it), it will show up as hard work for those involved rather than an opportunity to be enthused. The project will fail.

Decide for yourself. Read the article and leave your rating. I did.

When employees miss deadlines…look for failures in the system. Author, speaker and consultant Aubrey Daniels answers a reader's question about missing deadlines on software development projects. Daniels claims when an organization is missing commitments look to the architect of the organization — management. He goes on to say, "If employees frequently miss deadlines or rush around at the last minute to make them…the consequences for meeting deadlines are at fault."

• Look instead at how you set deadlines,
• How you respond to people when they meet them, and
• How you respond when they don't.

Daniels goes on,

The first is to assume success and plan how you're going to act when the employees are successful. What are you going to do and what are you going to say? The second is to have a way to see progress along the way. Put a large graph in the work area where everyone involved can see it every day. If you can track progress such as percent completion on a daily basis, you'll get a better result than if you graph it only weekly.

I only take issue with what to measure. Don't measure the typical percent completion. Instead, measure tasks completed (done-done) as planned. Otherwise, nice article.

If there is such a thing as expert project management you will find it from Max Wideman. Max offers a complete resource site for project management. His advice is direct, often funny, and based on year's of experience managing projects. I've been referring to Max's wisdom for quite some time. Take a look for yourself.

I received numerous replies to the posting Can the Reform of Project Management Succeed? Most were encouraging. Many came by email; while others were the topic of Yahoo! Group discussions. Here are ten of the best quotes:

• I think the project management theory is dated…(I) am a big fan of controlling variability Kalyan
• PM sometimes just has to be "enforced" from the top down. Buck
• If you ask for different reporting and you don't create jobs for traditional PMs and you don't hire any, you have a paradigm shift. David
• In an agile world, the PM's job is to keep the Issue Log empty, not draw the Gantt Chart. Ken
• I actually believe that this decade is when the entire project management paradigm is going to undergo a paradigm shift. Kalyan
• The theory & practice of project management IS stuck in a rut but that's not because of a lack of effort…No, it is mostly because project managers are sticking to an outdated technique. Namely GANTT chart style project planning. Chris
• Do we need to produce a change in project management? Or do we simply need to produce a change in the projects we manage?…If those of us who are passionate about eliminating waste in systems keep learning and sharing, we'll have impact on those projects we touch. Joe
• Tariq offered "these OLD quotes":
  • Every time material is handled , something is added to it's cost, yet not to it's value. - Henry Royce, 1907
  • It is not the strongest species that survive, nor the most intelligent, but the ones most responsive to change. - Charles Darwin
  • When the learner is ready, the teacher will come. - Taiichi Ohno
  • We don't have to change; survival isn't mandatory. - W. Edwards Deming
  • Real benefits come when managers begin to understand the profound difference between "cost cutting" and "eliminating the causes" of costs. Brian L. Joiner
• The schedule, which used to be the assumed management tool, is a path only marked in the distance now. At best it has always been a guess as to the steps needed. Steve
• The PMI will disappear unless its members embrace progressive paradigms. Marton

Long live the reform!