Herding Cats

Email, Twitter, and Social Networking the Basis of PM 2.0 - Yea Right

Twitter, email, Facebook and productivity killers.

From I Love Charts. All this PM 2.0 stuff will eventually catch up with the notion of physical progress to the plan, measured on tangible evidence.

The Perfect PM 2.0 / Web 2.0 Plan

Just like the underpants gnomes PM 2.0 has the Unicorns to help produce the beneficial outcomes

Task Dependencies

Project Management Tips has a contributor, Dana Larson, who posted about features needed in Project Management Software. These include:

• Collaboration
• Task Scheduling
• Multiple-Level Organization
• File Storage and Sharing
• Time Tracking and Reporting

Collaboration

There are numerous ways to collaborate, many are built into some project management software systems. Most all work in some way to keep people "connected." IM, WebEx, email, VOIP, etc.

Task Scheduling

Dana talks about individuals managing their own tasks. Tasks assigned to the team members, who can create their own schedules based on their availability and due dates for their tasks.

This is NOT a project schedule. It may be a "to do" list. But this list and the tasks on it, can't have any dependencies, or any critical dependencies.

This violates the fundamental of all project scheduling processes - there is no baselined control over the planned work. Imagine you and I have a dependency. I decide to make a change in the due date, because I'm not available next week to work on this task. So I'll push it to the right by a week.

How do find this out? How do you acknowledge I'm making that change? How do I know my decision doesn't impact your dependency?

This is the reason for the PREDECESSOR and SUCCESSOR fields in MSFT Project.

A really bad idea to allow individual to make changes to due dates and durations.

Multiple-Level Organization

The project management software described here sure sounds like a list making tool.

"Tasks in folders?" How are the PRED/SUCC relationships defined?

File Storage and Sharing

This is missing in many PM tools. MSFT Project Server does a pretty good job. Share Point with Project add-ons does this better. 

But the suggestion that files are of a higher quality with this sharing has not been our experience. Unless there is an editor, the files (documents, spread sheets, PPT presentations, Visio and the like) start to look like "cooks soup," and degrade to the lowest common denominator of content and style.

This is a Document Management and Document Control problem, addressed by Document Management systems. Sharepoint can do this. There are others, but leaving this up to individuals ends like like the Greeks say in Ovid

Pile a little on a little and get a big pile

Time Tracking and Reporting

I'm amazed how little this is understood. If you don't know how much time you've spent on something you don't know what it costs. If you don't know what it costs, you can't know what it's worth.

If you working on projects, you need time cards. Period.

Web Technologies and their actual impacts

The notion of Web 2.0, PM 2.0 and web technologies in general having positive impacts on organizations and especially projects is a popular discussion topic. Ranging from blatant marketing hype, to somewhat dubious web surveys, to actual refereed journal articles, there is a huge amount of information floating around.

This months IEEE Transactions on Engineering Management, Volume 57, Number 2, has a paper titled "The Strategic Implications of Web Technologies: A Process Model of How Web Technologies Enhance Organizational Performance, Barney C. C. Tan, Shan L. Pan, and Ray Hackney, pp. 181-197.

The abstract of the paper states

The lack of knowledge on 1) how Web technologies support the business strategies of an organization and 2) how Web technologies enhance organizational performance are gaps in the existing literature that may account for the inability of the majority of Web-based firms to leverage their investments in Web technologies. To address these knowledge gaps, a theoretical lens is constructed from five core logics in organizational literature that represent the different possible ways of enhancing organizational performance. ... Specifically, our study reveals that the process through which Web technologies enhance organizational performance is contingent on the state of the organizational environment. When the environment is in a state of equilibrium,Web technologies can enhance organizational performance by facilitating the attainment of competitive advantage through three distinct mechanisms: the logics of positioning, leverage, and opportunity. Conversely, when the environment is in a state of revolution,Web technologies can give rise to performance gains by supporting the attainment of legitimacy through two distinct mechanisms: the logics of optimality and social congruence.

So when there is a claim of benefit, whether from a product supplier or an interested party conducting a survey, care is needed to establish a domain and context for these claims.

The authors conclude:

This underscores the central premise of this paper that ... the effective leverage of Web technologies, is not dependent on technical excellence but rather the intricate fit between technology, strategy, and the external environment. By tracing the underlying process through which Web technologies enhance organizational performance in its entirety, and providing prescriptions on how to achieve the requisite technology-strategy-environment fit, it is hoped that if existing investments in Web technologies have not translated to better organizational performance, the process theory developed in this article can be used as a roadmap to help managers and practitioners to identify the “missing link” in the process, so that they may adopt the appropriate remedial measures to realign their investment to the path of success.

Success starts not with technology - never has never will - but with processes aligned with the strategic initiatives of the organizations. 

It ain't the tools, it's the process

Basic Rules of Managing Projects and PM 2.0

There are 1000's of rules for managing projects. I've collected many over the past 3 decades of managing projects. I came across a web site that has important things to say about project and program management.

Altis is the site of Jerry Maden, Associate Flight Director, Goddard Space Flight Center. Jerry has his 100 Rules for NASA Project Mangers.

But there is a critical important rule his states regarding PM 2.0 type processes. I'll paraphrase

Spitzer's Advice for Business Leaders: Never write when you can talk. Never talk when you can nod. And never put anything in an e-mail.

This is expandable every aspect of managing a project.

Using Social Media to Help Manage Projects?

Ryan Enders has a post about using Social Media to help manage projects. Notice "help."

Ryan mentions what social media is being used in an article in PMI's PM Magazine. The referenced McKinsey study claims:

• 69% of respondents reported "gains in measurable business benefits."
• 10% improvement in operational costs
• 30% increase in the speed with which employees connect with outside experts.

The PMI article states

Depending on how they're used, social networking sites, blogs, and wikis can be powerful tools for intra-team collaboration.

All this collaboration stuff is critical to project success. But is collaboration using the latest social media tools "project management."

Let's quickly review the knowledge groups of Project Management.

1. Project Integration Management
2. Project Scope Management
3. Project Time Management
4. Project Cost Management
5. Project Quality Management
6. Project Human Resource Management
7. Project Communications Management
8. Project Risk Management
9. Project Procurement Management

Now social media as a communication enabler can add value to the communication needs of these process groups. This is not new news. Even in our defense and space practice, we live on IM and SharePoint. Both might be categorized as Social Media. Team Sites, chats with people at multiple locations, document control, dashboards, WebEx, and other "connection tools."

But are these tools Project Management?

They support the management of the project, no doubt. But so did the HP9000 based electronic contract management and program management tools used at Hughes Aircraft for the AH-64 in late 1970's, described in Project Management Lessons Learned.

Was this called PM 2.0? Was it social media? There was chat across the terminals with remote vendors. There was collaborative development of documents and databases between multiple sites using the tools of the HP9000 (a wonderful machine with a very fast processor).

Project Status Updates using Twitter

As a emeritus program was fond of saying,

"Are you out of your ever lov'in mind."
You might as well scratch your project status on the wall of the men's stall.

First project status is ALWAYS a report of physical percent complete against the planned percent complete. This is a number, some percentage, which can certainty be sent bu email, IM, twitter, and even scratched on the stall.

But that's not the "status" of the project. That the physical percent complete at the end of the reporting period - weekly in our domain.

The status of the project is the face to face, or video face-to-face conversation between live people about how you got to that physical percent complete, what prevented you from reaching the planned physical percent complete, and what you're going to do to get back to GREEN for the next assessment of your physical percent complete.

The Core Paradigm Gap

Reporting a numeric value is not "Project Management." No matter how you restate the hype, chatting, twittering, posting docs in MOSS, looking at pictures on WebEx is not "managing the project."

It's exchanging information about the project - possibly. Exchanging information through a very narrow bandwidth channel. And since the channel is narrow, communication errors are mandatory.

Those suggesting PM2.0 of the next big thing have failed to understand that a successful PM relies heavily on face-to-face communication. The agilest know this and state this in their Agile Manifesto.

So how is it we've moved away from this fundamental understanding? I have some conjectures:

• Those conjecturing PM 2.0 don't actually manage projects, they develop software. And since PM 2.0 is a project tool, they assume those of us who manage projects will really like their tool.
• That the core understanding of the process areas and knowledge groups of PMBOK and similar items in other PM framework are either not understood, nor practiced, and both in the world the PM 2.0.

Show Me the Money - Ron Tindell to Jerry McGuire

Please show me in units of measure meaningful to our clients (Enterprise IT, US DoD, DOE) for "managing" projects with tools like twitter, IM, and other "social media."

Communicating with a Tuna Fish Cans and String

Geoff Crane of Paper Cut Project Monitoring described his TwitterView with Jhaymee Wilson. I had not heard of a "TwitterView" before this. It seems to be an interview over Twitter.

I've been interviewed twice this year (2010), once by PMI for an upcoming article and other time for a commercial Blog. Both times were around an hour on the phone and an editorial session after to do the "fact check" and final edits of the interviews.

What came to mind with Geoff's post is doing an interview with two tuna fish cans and a string.

We did this as kids. It's half duplex, low fidelity, highly distorted. Fun but not very effective.

Endless studies have shown that communication between people is largely through body language and expressions. Then comes tonality, and finally the words themselves.

Now I enjoy Geoff's Blog very much and the people he points us too as well.

But I still have not gotten my mind around the notion of Twitter as a communication channel for anything other than exchanging short - almost context free - messages. 

I live on IM with our field staff. It's a way to see who's in, a quick check up on something that can be resolved in a very few sentences - like ONE. For example - "who's using the WebEx account?" "Hey Matt, I'm headed to 59th facility, you gonna be there for lunch?" "Hannah, you coming to Breck this weekend with your roommates?" "Honey, stop by Safeway and get two bunches of green onions." Stuff like that.

Serious adult communication seems to require a wider channel.

Managing projects requires an even wider channel. In narrow channels we have, no hand waving, no doodling on the reports, no looking at multiple pieces of paper at the same time, no sensing of the facial expressions to see if we're actually exchanging information rather than just textual characters.

Someone please tell me what am I missing here, where the PM2.0 advocates claim this is the "next big thing," in the domain of Project Management?

PM 2.0 Post

I was interviewed a few weeks ago - out of the blue - by Herman Mehling. Outside the myriad of Journal papers and an upcoming PMI article, this is the first time this has happened to me.

Here's the words he captured from the interview.

Is Web 2.0 Redefining Project Management Best Practices?

In the end here's the point

• Projects are managed by people answering questions posed by the 5 Immutable Principles
• How they answer these questions varies according to the domain, culture and interest in using any specific technology.
• The tools of Web 2.0 and Enterprise 2.0 are not the basis of PM 2.0.

PM (Project Management) is a Verb Not a Noun

The Web 2.0 and Enterprise 2.0 tools are nouns. Project Management is a Verb. It's the verb of "doing" project management that might be improved with the Web 2.0 tools. Notice "might" and "improvement."

PM 2.0 is not the basis of success. Project Management is the basis of success irregardless of the version. The version is simply a marketing ploy to sell something new.

The 5 Immutable Principles of Project Management are just that, immutable - independent of the tools and people.

The Real Web 2.0

While the notion of PM 2.0 is still bouncing around, Web 2.0 impacts on procurement in the Pentagon is the title of an article in the current edition of Defense AT&L. "Defense Acquisition Enterprise 2.0," speaks to the use of Web 2.0 technologies in the acquisition process.

The message is "technologies can generate innovative methods to develop and field capabilities sooner by allowing those in the acquisition world to cut across functional stovepipes and better collaborate with the operational communities."

Tis was the case in the early days of the Crew Exploration Vehicle program where the Digital Environment was deployed to connect NASA, the Prime contractor, and the many subcontractors. These tools were crude compared to today - the dreaded "Live Link" product for example, was slow, cumbersome, and many times simply didn't work.

But just to remind those thinking collaboration is the same as project (or program management in this case) - it is not. The detailed face to face conversations needed to actually "manage" the program can never be replaced, with email, IM, blogs, wiki's social networks and the like.

The speed of information flow supports the management of the program. It is not a replacement for the hands on program management processes. It augments these processes only after they are functionally proficient.

In the same issue is LtCol Dan Ward's "Faster, Better, Cheaper" article - which was pretty much a "bad idea."

Is This Really How PM 1.0 Works?

Once again Andrew Filev - through Elizabeth Harrin - has a description of PM 1.0 straight out of the 1980's. This little story of how projects are chartered and then managed is reminisent of how projects were chartered and managed before personal computing.

It was not that long ago that a printed out Project Charter would be the start of project approval. The key stakeholders would physically sign the document, which would be passed in the internal mail between parties, finally returning to the project manager to update the version control for the document to version 1.0. She would then file it away for safe-keeping and proof that the initiation phase was over and that the real work could begin.

If "not long ago," means 1988 maybe.In 1988, I was the director of software development for a Fault Tolerant Process Control company, where we had world wide operations for our real time control system. All specifications, project plans, correspondence, and procurement approvals were done over email.

Steve Garfein essentially invented the notion of EDI for defense procurement on the AH-64 in 1974. HP-9000's used to exchange contracts, specifications, maintain configuration control and the Master Schedule for the Apache in Hughes Fullerton plant. Steve - a long time colleague - is an emeritus member of PMI, EPO of the Apache, Program Manager for numerous mission critical programs from defense to Dream Works.

He'd be surprised to hear that "not long ago," PM's filed the charter in a file cabinet. So would the 100's of PMs at TRW, Northrup, Boeing, Lockheed Martin, and other government and defense contractors.

Maybe the PM 2.0 folks need to get out more and see how all this talk of PM 2.0 has been in place for 3 decades

 

What is a Project Plan?

I'm working two programs in parallel - a really bad idea by the way. One is a DOE R&D project. The other is a DoD integrated battle management system.

Working in these domains produces a bias towards what is means when someone says "project management." This is an ongoing discussion for several reasons, not the least of which is how these projects answer the questions:

1. Where are we going?
2. How do we get there?
3. Do we have enough time, resources, and money to get there?
4. What impediments will we encounter along the way?
5. How do we know we're making progress?

In my domain these questions are answered through the Performance Measurement Baseline and several work processes used to execute the project with that PMB.

The PM 2.0 Examples of Projects

If I look at examples of processes used for PM 2.0, they are primarily "list management" tools. There are many examples of these. Ranging from email parsers, the task dashboards, to Share Point addins.

So here are some questions:

1. What types of projects can be managed with "list management" processes? These include assignments, due dates, narratives of the work on the list. All the stuff that the list management tools provide.
2. What are the limits of the communication channel using email, IM, and other Web 2.0 tools?
3. What is the evidence that the 5 questions above are being answered in sufficient fidelity to determine the project is moving toward success?

Looking at the users of BaseCamp for example, are they managing "operations" or are they managing "projects." When you look at their statements, many of the examples are "operational" in nature - ad agencies, and the like. Check list style projects.

I'm starting to see the target for PM 2.0 tools - projects without formal cost, schedule, and technical performance attributes.

PM 2.0 Communications Channel Bandwidth Requirements

What happened to the agile manifesto's first statement?

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

1. Individuals and interactions over processes and tools.

Are we really managing other peoples money by sending texts, chatting on IM's and exchanging and parsing emails around?

No meetings, no "war room," no big visible charts, no "team daily stand ups for the Scrum Team, no planning sessions, with cards and hand waving on the white board, no customer briefings?

According to Claude Shannon - effective communications is dependent on the channel bandwidth and the symbols sent over that channel.

In the late 1940s Claude Shannon, invented a mathematical theory of communication. His motivation was how to design telephone systems to carry the maximum amount of information and how to correct for distortions on the lines.

His approach introduced a simple abstraction of human communication - the channel. Shannon's communication channel consisted of a sender (a source of information), a transmission medium (with noise and distortion), and a receiver (whose goal is to reconstruct the sender's messages).

Shannon introduced the entropy rate, a quantity that measures a source's information production rate and a measure of the information carrying capacity, called the communication channel capacity. He showed that if the entropy rate, the amount of information you wish to transmit, exceeds the channel capacity, then there were unavoidable and uncorrectable errors in the transmission.

This is intuitive enough. What was truly surprising, though, is that he also showed that if the sender's entropy rate is below the channel capacity, then there is a way to encode the information so that it can be received without errors.

This is true even if the channel distorts the message during transmission. Shannon adapted his theory to analyze ordinary human (written) language. He showed that it is quite redundant, using more symbols and words than necessary to convey messages.

Presumably, this redundancy is used by us to improve our ability to recognize messages reliably and to communicate different types of information. In the study of complex systems today, we view deterministic chaotic processes as information sources and use Shannon's entropy rate, as adapted by Kolmogorov and his student Y. Sinai in the late 1950s, to measure how random a chaotic system is.

Now for Project Management Communication Channels

When we revisit the first agile manifesto statement - individuals and interactions over processes and tools - we can see that the communication channel capacity and the encoded information sent over that channel are critical to the understanding of the message.

So why reduce the channel capacity on purpose. Why restrict the number of symbols that can be sent over that channel (128 characters for example). Why not increase the channel capacity and increase the number of symbols. Face to face, pictures, hand waving, tonal inflections, body language, hands on touchable outcomes that demonstrate progress?

I have a speculation, OK several speculations:

1. Those suggesting the "next big thing" is a narrow half-duplex pipe with a limited character set are infatuated with the technology of these gadgets - IM, Twitter, and the like. It's part of their culture. They grew up with these tools. They think everyone will like them.
2. The projects they have applied these concepts to are their own projects. IT projects for the most part. They haven't worked construction, defense and space, energy, petrochemicals, pulp and paper. Projects like that.

In these project domains - and those domains where agile has succeeded - face to face, hand waving style communications dominates. Large enterprise IT has the same channel capacity needs. Possibly those 2 to 3 person 3 month projects that make up the vast majority - by count - of IT projects, such a narrow channel communication is effective.

But of course those showing the histograms of the number of projects fail to monetize those projects in the population of all projects. One large flight software program for a major weapons systems, swamps 100's of small 2 and 3 person IT software development projects. It's just bad statistics when such numbers are used

As Dr. Phil might say (had he read Shannon), "how's that - narrow bandwidth - limited character set channel - working for you?"

A Cautionary Note

The history of our future is filled with...

• moon bases
• jet packs
• 200 mph cars 

but has no...

• cell phones,
• Internet,
• and no laptop computers

Over the long haul, dramatic things happen to change the equation.

Sunil Paul, quoted in The Atlantic, “Better Luck This Time,” July/August 2009.

Via Wayne Abba's PMI Baltimore Chapter address, September 17, 2009. A former senior contract performance management analyst in the Office of the Secretary of Defense from 1982-99.

Forecasting the impact of the latest gadget, process, or method is very sporty business.

A $75 Solution to PM 2.0?

While responding to a post on Herding Cats, I came across a $75 Outlook based PM tool MissingLink Project Management

So minus the software interpreted process of Andrew's tool, what's the difference here? Outlook is ubiquitous, possibly on every desktop and cell phone in some form. It's highly configurable and like Andrew is fond of saying "as easy as email." It is email.

The Real PM 2.0

Working to determine the Ordinal Risk Ranking (Borda) for a flying machine IMP/IMS for a client. Came across some needed attributes of a collaborative project management environment. For example

• Project Management – Coordinating budgets, personnel, schedule, and products to meet requirements and mitigate risks
• Product Management – Transferring, storing, translating, and configuring within the context of a product breakdown structure that spans all levels of a program
• Process Management – Defining workflows, enabling approvals and concurrence, changing a products status, and notifying participants via e-mail
• Archiving – Aggregating designs, software, and data files into configurations and or compressing collections into files with indices and product descriptions
• Collaboration – Capturing comments, markups, revisions, discussions, and teleconference support
• Searching and Filtering – Finding information via key words, synonyms, and context within indices, product structures, and semantic information models
• Report Generation – Producing tables, spreadsheets, schedules, and diagrams that present data and relationships among people, products, and processes
• Information synthesis – Integrating data from multiple sources, plotting data, creating visualizations, and displaying results via portals and dashboards

When someone speaks of using light weight web tools (Web 2.0), email, twitter, and IM for managing projects, ask if the processes of project management can be supported in that way?

Now most projects don't have 1,000's of requirements. Ops, I forgot about Enterprise class software projects, large construction, organization change, commercial software intensive products, and things like that. OK, most project in the "long tail" paradigm probably have 100's or maybe even dozen's of requirements. Bet you the Google Phone has a 5,00 requirements in the end.

So if the requirements population becomes more than can be handled in an email, then something other that talking to each other through a 128 character pipe and collecting emails to guide the work of distributed teams, then more thought is needed to actually "manage" the project in the absence of any simple and simple minded tools.

Stop Tweeting and Start Managing

Projects are not managed through email, twitter, or IM. Project Management is about people talking face to face.

Can't do face-to-face. I understand. We work programs that have dispersed teams. It's part of the modern world. The teams are dispersed across town and across the globe. But in the end...

Project communication is NOT done through the narrow pipe of a 128 character half duplex ASCII character set messaging system.

Think of twitter as an ASR33 Teletype machine shrunk to fit in your hand.

To handle this problem of dispersed teams and their need to interact, is first to partition the problem across boundaries with minimal coupling. And to maximize the cohesion of the parts that have been partitioned. This is a fundamental paradigm of good software, hardware, and process design.

• Remove as much of the coupling as possible, this isolates the dependencies between locales. It also linearizes the flow of work. allow value to always be increasing with the minimum of sunk cost for rework and "do overs."
• Define a clear interface with exchange protocols that deliver 100% reliable items across the boundary
• Define a higher level process flow to assure value continues to move upward every time you send the next revision
• Think in terms of "system of systems" for everything other than a trivial problem

In other words start thinking about the "system," and stop thinking about the tools needed to implement that system.

As a system engineer, this SoS partitioning is done at the architecture level. There is product architecture, but also Program Architecture. This is the role of the Integrated Master Plan (IMP). Want to talk about the REAL Enterprise 2.0. It's a System of Systems, it's not Web 2.0.

The IMP describes the strategy for the successful completion of the project. It answers questions to the 5 immutable principles of successful project management

1. Can we tell where we are going?
2. Do we have a path to get to done?
3. Do we have everything we need to get to done?
4. What’s going to stop us from getting done?
5. How do we know we’re making progress toward done?

If you can't answer these questions in some credible manner with the people participating on the project, no cleaver Web 2.0 technology is going to save you.

Stop trying to solve the project management problems with new technology and new processes. No amount of re-analysis is going to improve the situation until you get your hands around those fice immutable principles.

PM 2.0 is going the way of early ERP systems. If I buy an ERP system I'll have better control of my business. It was simply not true. After billions of dollars then consumers of ERP systems finally figure out they needed to get control of the business in the absence of the ERP first. Then the ERP system could provide visibility, efficiencies, and other "incremental" improvements AFTER they had a credible process.

Project Management is not about email, IM, and WEB 2.0, it's about face to face communication around  the five immutable principles.

Technology is not the Solution - Again

Tom Barnett of Gantt Head has a nice article about the silliness of managing projects with tweets and IMs. I've been sitting in the conference room since the holiday break with my fellow PP&C colleagues,  trying to get a large defense program in sufficient shape for the Critical Design Review.

Sitting in the room with us are Control Account Managers, principle engineers, and subject matter experts. Our Integrated Master Schedule is a couple 1,000 activities - not that big. But it was assembled in pieces and now has to come together in preparation of headed to "baseline."

Tom makes the wonderful point that is completely missed on the PM 2.0 folks if they are working in the agile environment

Individuals and interactions over processes and tools

This concept is so ingrained in the agile world, and is now moving to the traditional world, why would we ever move backward and install "communication through a 128 character pipe, or a very narrow bandwidth of IM as the means to improve the probability of success for a project?

Sounds like a loosing proposition to me - sitting in our conference room and looking straight into the eyes of the CAM accountable for the software of our flying machine?

The answer may be:

"Common sense is the collection of prejudices acquired by age 18." - Albert Einstein

The common sense that drives PM 2.0, has yet to be tested with people older than themselves - the gray beards of PM.

Deconstructing the PM 2.0 Description

In an interview on PM411, there is a description of the attributes of PM 2.0. Setting aside the product promotion, I feel compelled to review the notions on which PM 2.0 paradigm is built.

As a practicing program manager in a variety of industries, I'd like to take each sentence and address the misinformation being used as the basis of the "next new thing."

Traditional project management is focused on the project manager being the center of the team’s communication hub. It places the manager in the center of the project work, as they need to collect all the information from team members, process it, and then communicate to various project stakeholders, including upper management.

Let's start with what PMBOK^® 4th edition has to say.

• Chapter 10 - Project Communications Management makes it clear that "project communications" evolves everyone on the project.
• Starting with the identification of the stakeholders, the primary goal of external communications is to mange the expectation of these stakeholder.
• A critical issue in this chapter is the distribution of information inside and outside the project.  §10.3 describes how to assess the needs of the project for starting with the "sender-receiver" model.

No where in Chapter 10 does it say the Project Manager solely performs this role. This is the first example of starting with BAD project management practice and considering that reason for a new approach.

Project planning can especially be hard and time consuming since all the project information is concentrated only around a single person — the project manager.

This of course is complete nonsense. Any credible project management method involves all responsible parties in the planning process. This ranges from the full team in a Scrum project to the Control Account Managers and their Technical Leads in a large defense programs.

Where this notion that planning ... is concentrated only around a single person - the project manager, may come from missing information on how GOOD project management practices are applied. No doubt the author may have experienced BAD project management, but a simple read of PMBOK^® would provide the needed guidance to see the statement is without merit.

There are alternative "planning" processes, PRINCE2 for example. IMP/IMS is one we use in defense.All credible planning processes involve "everyone impacted" by the plan. To do otherwise would be blatant ignorance of the role of "project management."

This contributes significantly to what a project manager spends 90% of their time doing – communicating.

This of course is one of the unsubstituted claims so common in the "next new thing" approach. Because if you're trying sell a new concept, one of the first impulses is to claim the competition is flawed.

New-generation project management tools make it possible to create a collaborative team space, and everyone involved in the project is able to contribute to the project work in this space. Project planning and communication is distributed around the whole team, and each team member has the full information on the project. Project progress is visible to everyone on the team.

The project manager’s role is transformed from the traditional taskmaster to become a project visionary as they focus more on the right direction for the project development. The new-generation tools take away part of the typical traditional burden of project management and allows the project manager to focus more on leading the project team.

I guess the web based collaboration tools, ones that have been in place for a decade, are insufficient to meet the PM 2.0 paradigm.

Of course this is one of those unsubstituted claims again. My sense is it comes from not having been a project manager before 2001 when all those things described above were in place in many forms - not Web 2.0 forms of course. Many were implemented in crude ways - sticky notes on the wall, or the Big Visible Chart hanging in the hall of Building O6 at TRW. Yes it was printed out overnight - every night - and not interactive through a workstation. But the first Sun Workstations were used to "display" this information. Bill Joy, BTW, helped us debug the memory manager for our embedded version of Real Time BSD Unix.

This may be the basis of PM 2.0. All the GOOD PM processes that have been around for ever re-hosted on Web 2.0 tools and re-branded as PM 2.0. But of course that's not what the author is saying.

As a short story of the each team member has full information on the project or the supposed missing information in PM 1.0. When we came in through security process every morning, if you saw your name in the Big Visible Chart in RED, then you knew shortly the Control Account Manager would be dropping by.

With Project Management 2.0, the project management of a project is built around the work, rather than the work being forced to conform to a particular project management system.

This of course is more nonsense. The only reason for a project is to produce an outcome. This outcome comes from work being forced to conform.

So now it's clear. The project participants are predisposed to "follow the particular project management system." This is the very basis of projects and project management. Whether this "project management system," is XP, or Scrum, or Crystal, or all the way up to DoD 5000.02 IMP/IMS the success of a project depends on conforming to a particular project management system.

Now, New-generation technologies have brought collective intelligence into the project management process. and open the way to another successful practice, emergent structures, where the one-to-many approach of conventional Work Breakdown Structures (WBS) is replaced by a many-to-many approach of work package delivery.

This is a fundamental violation of one of the immutable principles of project management - describe what "done" looks like in units meaningful to both customers and suppliers. The many-to-many relationships violate the transitive closure problems in databases. Multiple - and likely inconsistent - descriptions of the same thing.

So the take away from the PM 2.0 description seems to be:

Use PM 2.0 to do your own thing, 'cause we sure don't want to be hemmed in by following a particular project management process do we?

So How Can PM 2.0 Actually Be Put To Work?

• Use tools to remove impediments to visibility by homogenizing the information. This means standard units of measure, predefined assessments of "done." Things like that. This of course is difficult in any enterprise because of missing Enterprise Architecture to gain access to the needed information.
• Use tools to build a seamless traceability up and down the "fidelity" chain. From Capabilities descriptions in the business case or Concept of Operations down to working product test scripts. This is a real challenge since these tools started as standalone domains.
• Significantly reduce the cost footprint on the desktop. With multiple applications on the desktop the cost of information access is prohibitive, forcing a small number of users being allowed to this information.
• Provide "work flows" that can adapt to the changing needs of the project. This means tailoring within a PM method at the project level.

This last piece from PM 1.0 is the real burden on the project. The suggested burdens above are simply BAD PM. Provide low cost access and this narrow access channel to project information is removed. And you get PM 2.0.

So do this and stop all the red herring blather, which is simply BAD PM'ing from day one. Read PMBOK or any BOK and learn how to do PM right.

The Toyota Way on PM Technology

It's a cold but sunny day here in northern Colorado. I've been giving some thought to the issues of PM 2.0 and the method of "push" of technology onto projects. Not as a replacement for PM 1.0 as I'm now hearing the proponents say. But as an alternative approach.

I'm looking at the Toyota Way on the bookshelf and the 14 principles developed at Toyota. One stands out in this context.

Use only reliable, thoroughly tested technology that serves your people and processes.

Now the key here is both the people and the processes. The people are complex adaptive systems and can pretty much make use of anything that isn't completely lame. And sometimes even lame things can be put to work.

But it's the process that is critical in the Toyota process. Not more critical than the people, but this purpose of this discussion it is more important. The leading voices of PM2.0 have for the most part skipped over the processes of project management. And replaced those processes with self-centered process. Personal communication, personal fulfillment, personal interest. As we mention to our young college students "It's not about you."

In fact it's about the project and the processes that enable the project to proceed on its planned course.

So next time you hear a statement about PM 2.0 or any technology for that matter. Ask yourself...

How does this technology serve the project's processes and the people that use that process? But it's the process first.

A Sweet Spot for PM 2.0?

In some organizations project management is seen as an unnecessary overhead or a burden on the business. Looking at the best practices of organizations where project management is the raison d’être can guide our search for best practices in your domain.

Here’s one example of a successful project management approach. There are many others that might be appropriate for IT projects

From “Seven Key Practices of Program and Project Success – A Best Practices Survey,” Vincent J. Bilardo, NASA Glenn Research Center, NASA Project Management Challenge Conference, Galveston Texas, March 21–22, 2006, these practices are:

1. Establish a clear and compelling vision
2. Secure sustained support “from the top”
3. Exercise strong leadership and management
4. Facilitate wide open communication
5. Develop a strong organization
6. Manage risk
7. Implement an effective development and integration system

Number 4 appears to be the sweet spot for the PM 2.0, Web 2.0 based tools. The other 6 are left to the skills and experience of the project manager.