What

A set of rules for having efficient status meetings.

Why

Reading is faster than listening.

Status meetings should provide communication, not problem-solving or decision-making.

People don't usually need to be in all of each meeting

Who

Up to seven people or groups. If more than seven people, report by group. Five is better.

When

Every reporting period. Could be daily, every other day, weekly, monthly. First thing in the morning is a good time.

How

Everybody types out a PPPD the night before the meeting. A PPPD is four lists:

• Progress since the last meeting. Progress can usually adapted from previous Plans, from timecards, from personal To-Do Lists, from calendars, whatever your personal system is
• Plans until next meeting. Anything that stays on Plans for a second PPPD in a row should be marked (second time, third time). By the fourth time, you should move it to some wish list, because it’s clearly not a realistic, short-term Plan.
• Problems which are interfering with progress.
• Discussion points. This is anything you specifically want the group to talk about; it doesn't have to be an item from your P lists.

All PPPDs are distributed to all participants by end of business the night before the meeting. The Secretary reminds anybody who is late. Participants should read all of the PPPDs before the meeting.

The status meeting has three parts. The secretary manages the meeting.

• Review
  • Review goes one PPPD at a time, in the order they were sent.
  • Review consists of author saying good morning, asking if anybody has questions or responses to any of their PPP items, and then Q & A as needed.
  • Talking during Review is limited to brief question and answer, clarification, etc. Anything more than 30 seconds should be interrupted and added to the end of the Discussion list for that PPPD.
  • Continue until all people have Reviewed.
• Big Discussion
  • Go around all of the PPPDs again, in the same order
  • For each PPPD, raise each of the Discussion items in the order written.
  • If it only concerns a few people, bump it to Small Discussion.
  • If discussion goes more than a few minutes, bump it to the end of the meeting, or later.
  • Continue until all PPPDs with Discussion points have been covered.
  • Anybody not needed for Small Discussion leaves the meeting.
• Little Discussion
  • Discuss remaining discussion items, if any, in the appropriate smaller group
  • The secretary takes notes on any decisions made, and sends the notes around, and reminds people when the next PPPD is due.

Failure modes

Nobody reads the PPPDs. If this happens, go ahead and spend the first ten minutes of the meeting letting everybody read quietly while music plays.

People are late or miss meetings. You can punish the latecomers by making the last PPPD author be the secretary for the next round, but they will probably be a lousy secretary and you will have to nag them to nag other people. Unless your entire team is well-motivated (or anal-retentive), the natural nagger should remain the Secretary.

Acknowledgements

The PPP meeting process was passed tome from one of my mentors, Grant Tegtmeier, who also helped refine it into PPPD. The Progress/Plans/Problems template, of course, predates us all and presumably can be found in Sumerian tablets explaining why the new ziggaurat is running behind schedule.

The speaker is introduced as working in a field undergoing a "once in a lifetime" change. After all, "we won't go digital twice." In a narrow sense, though, that's precisely wrong. Congress extended the deadline to replace analog television signals to digital from February 17 to June 12. The stations had all scheduled engineering work for the transition, including physically moving transmitters around on the broadcast towers, and a quarter of the stations chose to stick with the original date. So in fact we are going digital at least twice.

The speaker works in the field, managing installation of broadcast television studios. The following is my paraphrase of the speaker unless otherwise noted.

Why is this delayed? No project management. Fighting between agencies, no one in charge, etc.

Q: Whose project is this? A: Nobodies. Nobody is in charge of it. Stakeholders: NAB, the public, FCC, NTIA, consumer electronics companies, broadcast equipment companies, system integrators, cable companies, satellite providers.

Why was it delayed? The NAB went to the incoming Obama administration warning that some people weren't ready for the transition, in total about 1% of all Americans.

The history of analog TV. Some tech terms. Ampex developed the first commercial video tape recorder. ATSC is the name of the technical standard for digital TV in the US and the committee that came up with the standard. It used to be called the Grand Alliance, although that term is out of use. Europe has a different standard. DTV is not the same as high definition. ASTC is a set of different standards, some of which are hi-def and some of which are not. Up to five standard-def streams fit in one former analog channel. The major US networks have chosen different ways to divide up their channels; only two are actually using the full resolution, 1920 by 1080.

HD dates back to before 1980. Broadcasters wanted to switch to HD to gain a competitive advantage over VCRs and other new competition. "Now they're getting their wish but it's almost too late, right? ... Broadcasters are almost playing catchup at this point."

1600 local stations already broadcast in DTV in parallel with their analog. Total spending for equipment, government coupons, etc, is roughly five billion dollars. The government plans to auction freed up spectrum for 20 billion dollars (after apportioning some of it to fire departments and other emergency responders). The current transation plan, such as it is, dates back to 1996. There was a previous deadline in 2003 that passed without consequence.

The use of television as an emergency communication system. On 9/11, many internet sites were not updated in a timely fashion, and only TV had fresh data. That's changed somewhat since 2001.

HD is a wider aspect ratio than SD, and there was discussion of selling the bars on the side as advertising. When I was doing the KCAL transition, Neilsen didn't have high-definition boxes.

Q: What about the adoption of HD/digital in less developed countries? A: The prices for HD are dropping because of investment here. At the same time, all of the existing SD equipment in the US is obsolete and will be sold cheaply.

Q: What would you do as president in 2001 to make this run better? A: Appoint a project manager ... this was run by politicians and their interests ... do traditional project management, get the stakeholders, get a plan .... Q: So you are saying we can use this as an example of what happens without project management? A: yes, it's a trainwreck.

This presentation was a bit disappointing. I've been following the DTV switch for years, through my own reading and, of course, from Harry Shearer's ongoing "Digital Wonderland" updates on Le Show. I though this event might feature some insights, stories from the trenches, etc, but it was relatively shallow.

A PMI Silicon Valley Tools and Techniques event, sold out: Practical Scrum for PMPs. The PMI SV chapter is extremely active, with one or more events just about every week. 14 women, 21 men.

The first attendee introduced herself as requested, and her motivation for attending was that her company is starting a new Scrum project. The second attendee introduced himself as on a date with his wife, the first attendee. The room then erupted in laughter.

The rest is my paraphrase of highlights from the speaker, Sutanu Ghosh, unless otherwise noted.

The PMBOK (Project Management Body of Knowledge) does not conflict with Scrum. PMBOK provides a framework; Scrum is a specific practice that can be understood in that framework.

Toyota is big on agile manufacturing, which is very similar to agile programming.

Existing processes may be too heavy and offer too little reward. This is a premise of six sigma—pruning useless processes.

Information saturation: the more aware you are of your teammates' activities, the less documentation you need.

Traditional view: the trilemma of scope, time, and cost. In the agile view, think of time first, then resources (cost), then features (scope). Joel's note: I'm increasingly questioning the validity of this model, either flavor, in software. The overwhelming cost of software development is salaries, so aren't time and cost co-variant instead of in opposition?

Stopping the release, or halting the assembly line, is positive to the extent that it represents the voice of the customer. E.g., the customer would not want this car or this software with this defect. But it shouldn't become a gotcha war between test and engineering.

Under what conditions is an Agile method applicable?

high complexity	phase-gate review (product lifecycle)	?
low complexity	informal	agile
	low novelty	high novelty

Scrum is extremely applicable to adding incremental changes to an existing system. It is also applicable to trying a novel assembly of existing parts. It is less applicable to problems with uncertainty in both sides: building a big complex whole with undeveloped parts. Scrum with long-term commitments is not Scrum, it's rolling wave.

Scrum requires sequestering your resources; they should be wholly committed to only one project for the duration of the sprint.

Discussion: if there are external commitments going far into the future, how can you use Scrum to get internal commitments to match? This comes back to the basic paradox of development: sponsors understandably want predictability out of an inherently unpredictable process. One partial answer is that Scrum is not suitable for an environment that can't accept scope churn. Joel's note: to me, the real difference is simply style. Declaring that something must happen in two years, and even threatening contractual consequences, does not cause it to happen. A waterfall process will spend weeks or months understanding the problem and then return an estimate of whether or not it's possible and what the risks are. An agile process will get started on something that seems like the first step today, but refuse to answer whether or not it's possible until it's almost done, which may or may not be in two years.

As teams grow, communication effectiveness drops exponentially. A team of 7 +/- 2 has optimal communication.

The product owner represents the customer. In Six Sigma, this is the concept of customer voice as opposed to engineering voice. The job of the product owner is not to give the team activities to do. It's to give them stories to realize, stories which can be sold to customers.

One difference between PMBOK and Scrum (and probably between PMBOK and reality) is that, in PMBOK, the project manager implicitly has some authority. In Scrum (Joel's note: and in my experience), the project manager does not have authority, only influence.

Scrum principles can help keep the counter-productive dart-throwers out. Pigs vs chickens. The voice of the customer is very important. People with an interest but not stake should not have influence.

Stories should be: independent, negotiable, valuable, small, testable.

A traditional requirements document tends to mix up structure and behavior. Attendee: I was taught, years ago, that the functional specification is written in the language of the customer. The design spec is written in the language of the engineer.

The recommended length of time for a sprint is four to six weeks. Some say two weeks.

People who write user stories often forget things like regulatory compliance.

Technical debt is cost that will be incurred later in product lifecycle due to negligence now.

Scrum plans are based on bottom-up estimates of how to meet top-down targets. There is still uncertainty, just as with other engineering. Accuracy is much more important than precision.

My questions:

• I've been working in software and IT since 1995, which is long enough to see some ideas come back under new names. (For example, SaaS, which used to be ASP). But I haven't seen a direct match to Scrum. What was the closest previous trend to Scrum, and when did it fade, and why?
• "It's called a sprint because you are running hard. As the program manager you drive the team to work very hard." From my reading I though the essence of Scrum was management putting giving a team three things: isolation from distraction, a clear target (or a commitment to give clear "warmer/colder" responses to output), and freedom to choose their approach; and this the ultimate purpose of all this is simply to get the team self-motivating. So why do you say that the program manager drives the team? Isn't that antithetical to Scrum?

I'm attending my first PMI event in Silicon Valley. (see previous entries about PMI). My PMP certificate expires at the end of the year in March 2010, and I need 60 Professional Development Units to renew. I have 28 units. Tonight's event, "The 10 most common mistakes PMs make when looking for work", is worth 1.5. There are 150 people registered and seven walk-ins. We passed a microphone around to introduce ourselves by name and company. Aside from the typical Silicon Valley (Sun, Apple, Applied Materials, etc), 3 are unemployed, 22 are looking, and 6 didn't give a company. This is probably the most diverse PMI crowd I've ever seen, in terms of ethnicity and gender (although still mostly male and majority white), but perhaps the least diverse in profession, spanning IT hardware to IT software with maybe 1% other.

The speaker follows, in my paraphrase unless otherwise noted:

I'm going to talk about the mistakes I see people making over and over and over. My background ... Air force ... staffing company. We put on a conference called LavaCon, in Hawaii, but in 2009 it'll be in New Orleans. And I have a Mardi Gras necklace here ... Tonight is about group participation. [He has a big bag of chocolate and is throwing chocolate to anyone who asks a question.]

Recruiters get many resumes every day. Your first job is to make the recruiter's job easier.

1. Most important: Summarize how your skills meet the requirements. E.g., make a table directly linking your experience to requirements.
2. follow the submission directions. "We'll say, 'please send me your resume and a summary of the IT projects you've done.' And I'll get a submission, 'here's my resume'."
3. If it's been 2 weeks and you haven't heard anything and the ad says "Don't Call", what do you do? Find somebody other than HR, and call with something reasonable, like, "I wanted to be sure my resume was received".
4. Should you send salary history if requested? Maybe. You could respond with: "Salary requirements commensurate with requirements of position". Or with a range. Joel's note: Extended discussion proceeds on how to deal with salary-requirements gates. I think this mostly misses the point since this implies going in the through the main screening door, which is mostly a lost cause. The presenter seems to feel the same way ("Uploading your resume to Monster and waiting for people to call you is not looking for work.") but takes a bit too long to curtail discussion, so I remind myself that I get PDUs here even if I don't get much immediate job help.
5. Try to get your resume to the right person directly.
6. Distinguish yourself from other PMs. Network at C++ meetings, Java meetings, instead of PM meetings. Look for the "High Tech professional council", "Silicon Valley Chamber of Commerce" is good at listing high-tech companies in the area. "Web Guild." Write an article for the PMI newsletter, and interview people for that article. Send them thank-yous with "by the way, you mentioned you were hiring in June. Would it be okay if I contacted you then?"
7. Volunteer with PMI and other groups. Q: How do you decide which networking events to go to? Joel's note: figure out what you want to be doing, and who's doing it now, and what groups they would belong to.
8. You can't wait for your ship to come in if you haven't sent out a ship. You have to send out a lot of ships. Every time you go to a network event, that's a ship. Every time you hand a card to somebody you met at a Safeway, that's a ship. And it could take two years for a ship to come in.
9. Use the job sites to figure out who's hiring, and then follow up directly or via networking.
10. When getting to a decision maker via network, get your proxy to sing your praises, especially if you're not an exact match.
11. The order of qualifications in the list is significant. Do stretch a little, but stay in the ballpark.
12. Put your cover letter in your resume document so they can't be separated.
13. For full-time positions, apply with a chronological resume. For contract, a functionally organized resume.

End of presenter's material... We're already ten minutes over so I skipped out on the drawings for various prizes. I did ask one question during the meeting: How do you find companies that value your PMP certification. No good answer: companies that value PMP will post on the PMI website. Search for PMP on Dice or Monster.

PMI-SV in creating a new job search group, Friday mornings 7:30 am to 9 am, in Cupertino.

During the networking break, I talked to my seatmates, and got a nice reminder of the three elements of the PM's job: "People, process, tools".

Summary: good refresher on the basics. A few little things particular to PMs, mostly in figuring out who might need PMs based on other observed activity, but 98% generic. I'm already doing most of the good stuff and avoiding most of the dumb stuff. I picked up one interesting idea, which is to make the cover letter a direct mapping from job requirements to matching experience, the point being to save the HR person or recruiter from digging through my resume. I already do this in text, and I already stick with a pretty lean cover letter, but I like this idea of spelling it out. So, on the content it's a win, the guy was entertaining, I may steal his idea of dispensing from a bag of candy throughout the event (with an option for diabetics), and now I have 30 PDUs.

PMI is the Project Management Institute, the biggest and oldest institution in my profession. I'm voting for the Board of Directors. There are nine candidates, three women and six men, and I can vote for up to five. Here are some quotes from candidate statements:

My vision of PMI is to be globally recognized as the de facto advocate for project management, and the key transformation agent through its innovative products, services, programs and partnerships.

PMI's position as the global thought leader in project, program and portfolio management and the authoritative source for all aspects of project management knowledge has been reinforced to me as I have worked with project managers from around the globe.

Second, remain the "Thought Leader" in project management by continuing to be the "go-to" organization for practitioners and corporations looking for project management information.

Finally, PMI must remain a forum for thought leadership in the project management profession

PMI has made significant progress to establish increased membership and presence in various regions, but a stronger focus on a large part of the African region is strategically needed.

As a Board member, I would advocate for PMI's thought leadership in bringing together diverse stakeholders (e.g., academia, corporations, vendors) and professional associations (e.g., engineering, IT, other project management associations) to promote compelling messaging around the value of the profession, and common approaches to its practice.

Slim pickings, you can see, although one of those quotes is markedly different from the rest. Most of the statements are fairly pure bullshit, of both the ב₀ and ב₁ varieties. None of these people seem likely to address what I think is the fundamental weakness of the profession and the institute: the pressures to stop dealing with reality and start dealing with an artificial world instead, a world in which "thought leadership" is a meaningful phrase.

In reaction to the huge response to their last event, SPMI's schedule is blossoming with events. Another full room today (A few more ang moh's here today. Apparently we're all doing the shaved head thing now) for "Collaborating with the Enemy", by Steven Blais of IIL. This event is S$10 for SPMI members, including a very tasty Indian Vegetarian meal (places in the world that have to deal with halal and other religious requirements tend to be very kind to vegetarians as a bonus. Some sort of drawing with a prize over $1000 is announced, which gets a loud murmur going as people dig for their business cards. Given that S$10 each probably doesn't cover catered meals plus rental, IIL must expect to drum up a lot of business here.

Joel's executive summary: Projects must solve problems. Problems come from business. Business analyst, project manager, and system analyst are distinct and mutually exclusive roles. The business analyst role is responsible for ensuring the project solves the problem.

The rest of this post is my paraphrase of the speaker unless otherwise noted.

The great gap between project managers and those people who want our services. We have to bring in projects that are on time, on budget, and have all the features we promised. And what keeps us from doing this? The customers! When I started they didn't have this gap, they didn't have users. My first system was the automated payroll for the Navy. Punchcards, line printer. Chesty Puller: "I don't really understand this stuff; we have a printer that can print 1400 lines per minute; who can read that?" Not much user interface, the users worked with us, it was fine.

The project manager: what are your requirements?

The business person: I have a problem. You're the IT, you fix it. What are requirements? I have a problem with the annuities system.

PM: Give me some requirements

B: Well etc etc

PM: (to self) this is great, I can use that new java framework and ...

Joel's note: it doesn't seem like hilarity is going to ensue. Summary: the project manager and business person have different goals, contexts, and languages. Process-oriented business versus project-oriented project management. Business teams are together for years; project teams may last two months.

Anecdote about delivering a computer system to which the user responds, "it doesn't feel good." After many weeks, this was articulated into how it looks, how the mouse moves across the screen.

Standard personalities for technical people: INTJ (that sounds familiar. Now can we get the stereotypical FIRO-Bs?). For business people: ESFP.

How does the gap affect the project? changes, delays, scope creep, cost overruns. What tools help deal with this? change management, product acceptance. Joel's note: Hmm, agile techniques are one way to try and deal with this structural problem. I wonder if he'll talk about them, or some other approaches? Here's some thinking on integrating Agile and PMBOK.

I won an award 35 years ago for a US Navy project. On time, under budget, delivered everything promised, never had a defect reported since delivery. Of course, it was never used, and we knew it would never be used before we started working on it. Best project I ever did, because there were no users to mess it up. The point is that a successful project is not the same thing as a successful business. Projects are tactical, not strategic. Strategic business people should not be involved in projects. But now there's a gap between the business needs and the project. Who fills the gap? The PMO? No, it's not their business either.

Let's fill the gap. Organizations have a role for that, whether they label it or not: business analyst. Most of you PMs also do that role. The business analyst's job is to ensure that the project produces a product that solves the problem. The business analyst is a bridge.

As a consultant, I'll be working with a company to improve their project management, and I'll ask, what do you see the role of the business analyst as? And they say, they're a bridge between technical and business. Actually, they are a bridge between problem and solution, which may or may not be technology. The definition of the solution is the requirements. The business analyst establishes the bridge and the project manager gets us across the bridge. In SCRUM we call them the product owner. (Ding! Agile mention. Quick sidenote: I don't want to be mistaken for an Agile cheerleader. My own experiences with Agile are mixed. Whether or not one or more Agile methods is a good solution, they are at least addressing the right problem, which is basically this same gap he's talking about.)

Business Analyst is a role: they define the real business problem, completely and accurately; and "maintains full communication between stakeholders with the problem and solution team". At IBM we weren't allowed to have problems, only challenges.

The business analyst should ask, how will you know that we've solved your problem? If there isn't an answer, there isn't a problem. When we have that, we have acceptance criteria, a contract. The issue is that many times, the business doesn't know their real problem. Incidentally this happens well before we have a project.

If customers get more features, it's scope creep. If IT throws in some extra things, it's gold-plating. Notice who's naming these things.

Incidentally, this guy is a very good speaker, even though he's got powerpoint in the background. I think he could spike 80% of his slides, leaving only a few diagrams, and be better for it. But perhaps the other, wordier slides, which he generally ignores, are helping the readers? Anyway, he's very animated, vivid; you can see the punchlines coming but that just makes it more intimate.

Users don't have requirements; they don't know what's possible. They develop requirements together with the technical team. It's not if the requirements change, it's when. Plan for that evolution and you won't have creep. Halting scope creep won't help if the product doesn't solve the problem, e.g., have the right scope; if the product doesn't solve the problem, why are you making it? And, scope can't creep unless somebody agrees. It's up to the PM to say no to anything that doesn't solve the problem. Um. It feels like there's some sleight of hand here. How can you predefine the scope, given that we've agreed that it's impossible to understand the requirements before you start? I'm not convinced that scope exactly equals problem.

A need is not a problem. Why do you need it?

PM has conflict of interest. PM defines the project she's responsible for, and may push for a better project rather than a better solution. The business has a conflict of interest: it is not objective about the problem or solution. Businesses rarely do due diligence over the project: creating a charter, determining ROI, etc.

The business analyst starts before the project and ends after the project. The business analyst communicates changes back and forth between the business and the project. After project close, the business analyst is still confirming that the delivered product solves the problem. "If you have a solution that does not create at least three new problems, you have the wrong solution." If you are a PM who is also a business analyst, skip the party, go down and have just one Singapore Sling with the project team, then go back and see if the product works in production.

What's the difference between business analysts, project managers, and system analysts? They all do the same functions, (plan, manage risk, work with stakeholders, requirements, test, estimate, impact analysis, evaluate alternatives). But they all do them differently, for different people. BA does acceptance tests; PM tests project plan; SA tests integration. How to test the project plan? The plan breaks everything down into work tasks. Each task has an input and an output. You test the plan by ensuring that all inputs and outputs are used. You test it by laying out the tasks with your team (not with MS Project, but with the actual people). BA focus is business; PM focus is project; SA focus is technical. It is very difficult for one person to do all three roles, especially if they aren't trained.

How many of you grew up and went to school and said, I want to be a project manager. We're almost all accidental project managers. There are people who grow up to be systems analysts, go to school for that. Hopefully some day there will be schools for PMs, fraternities, etc. These three roles call for different personalities, different talents.

BA to customer: Is what you are asking for going to solve your problem? My job isn't to build something, it's to solve your problem.

(Side note because he said something about dodgeball: this is cute but raises the disturbing question: why would you pay three dollars to see the equator?)

How to wear two hats: As the PM, focus on the team. As the BA, don't let project noise (deadlines, etc) influence your relationship with stakeholders. I literally had different hats that I switched back and forth depending on the work I was doing.

First, make sure you understand what the role of the business analyst is. Keep the roles separate. Write the requirements as a BA; come back as a PM and pretend somebody else wrote the requirements.

about ten people just got up and left simultaneously. It's 8:35; are they all going to catch a bus, or like CEOs giving themselves raises, did they just realize that they could leave? The speaker is good but it's true the crowd (myself included) has been drifting for a few minutes.

An abrupt ending, and only one question. I think he could have wrapped up ~8 minutes earlier and had 10 minutes of good questions.

Q: Who has authority? A: The project manager has authority and accountability for the project, the BA for the business.

The Singapore branch of the Project Management Institute isn't especially active, which is surprising considering Singapore's reputation for management. If you hold the PMI's "Project Management Professional" credential, you need to earn 20 PDUs per year to maintain your credential; a PDU is a "Professional Development Unit" and you get them from attending seminars and meetings and such, at about one PDU per hour. The Puget Sound and San Diego branches (home to Microsoft and Boeing, and to half the US Navy, respectively) offer monthly breakfasts, dinners, and whatnot so you can pick up PDUs steadily. Singapore's branch does very little, aside from an annual all-day seminar that's only worth 8 PDUs.

So when they announced a seminar for Monday night, on a topic that's not completely boring, for two PDUs, and for free for local members, they should not have been but were surprised to get 270 registrations instead of the seventy they planned for. I'd bet that the total number of credentialed PMPs in Singapore is probably right around, oh, 270? Anyway, on to my observations: Attendence was announced at 270, which seemed about right. Counting the five rows around me, there were 44 people, of which 10 were women. Mostly Chinese, but a strong Indian representation. If there were Malays, I couldn't clearly spot them, but I'm not so good at telling Malay from Chinese without staring or telltales like headscarves or names. Two people carried on extended conversations on their cell phones; the local norm is apparently that it's okay to do this as long as you talk very quietly and cup your hand over your mouth.

---

The talk was by Assistant Professor Lieven Demeester from INSEAD (an international business school), previously a management consultant. Following is my paraphrase of the speaker, unless otherwise noted

• What's new in the last few decades in project management and uncertainty? Game theory, psychology, etc. And globalization.
• If you plot the chance of a task completing against time spent, with time on the X and chance on the Y, you get something like this (Joel's note: found this on Google, not from the seminar): There's a 50% chance the task will end within, say, 10 days, and a 95% chance it will end in 20 days. If you ask how long the task will take, an answer with a single number is misleadingly simplified. It's probably going to take about ten days, not much less, very possibly twice as long, and maybe even longer.
• The consequence of this is that if you ask for an estimate and they are conservative, it will come back much closer to 20 days. Then the schedule gets built around these estimates, and they reify. That is, the (longish) estimate becomes the reality; workers will pace themselves to complete the task at the "deadline", called the "college student" effect. If the task is completed early workers will probably go and do non-critical work until the deadline instead of reporting completion promptly. If they are juggling several tasks, especially with several bosses, they will load-balance tasks, which may be optimal for them but sub-optimal for the big picture. And even if early completion is achieved and reported, other people may not be ready to start early.
• Goldratt's solution with "Critical Chain Project Managament" from 1997 is to set the expected duration for each task on the lower side of the estimate range, and then put the difference between low and high estimate for all of the tasks into a single, project-wide buffer. This has two benefits:
  1. The earlier dates motivate everybody
  2. Because the buffer is based on lots of individual risks, it's more accurate. (Under the same principle as insurance: Even with good historical data telling me you have a 0.001% chance to crash your car every day, I can't predict if you will crash today. But if there are a million drivers, it's a safe bet there will be about ten crashes per day.)
• "It's very hard to eliminate multi-tasking" but you should try
• Joel's paraphrase: Failure is an option, in fact small-scale failure is nearly certain, and you should plan for it.
• Some of the cognitive biases that hide risk: framing the issue too narrowly, overconfidence, confirmation bias (counting the hits and forgetting the misses), escalation of commitment.
• Well-managed projects are boring and appear to have a lot of time wasted on risks that never happen. Joel's note: we end up with an Institutional Design problem: how you do structure an organization so that finding and mitigating risks is rewarded instead of punished?
• Four strategies to manage risks (this was arranged in yet another two by two matrix, probability of risk vs impact; I'll let you figure out which strategy goes in which box): let it run but monitor it, delegate, control (with help from above), and actively manage.
• Two strategies to deal with unknown unknowns
  1. Iterate and learn. Joel's note: Examples: China's economic policy, called "crossing the river by feeling for the stones one step at a time"; agile programming, spiral development, etc. Timing depends on the speed of learning. Note that this strategy requires the capacity to learn
  2. many parallel attempts. Example: electronics and car manufacturers rolling out many products and then discontinuing the losers. Internally competing teams to build the same thing.

Overall, I think this was a great event, because it did exactly what it's supposed to do: teach some new lingo and buzzwords in use in the field. I learned things I didn't know, I could imagine applying some of it, and the speaker was competent at presenting. It was only during questions that the quality of the event dropped: the question I remember was in two parts: why are you talking so much about CCM and not at all about CPM, the last big buzzword? And how do I do CCM if my client wants firm deliverables?

Unfortunately, the speaker chose not to give direct answers. For the first, he danced around so much I'm not sure what the answer was, other than that you can buy CCM add-ons to some CPM tools (which could mean anything; vendors love to be buzzword-compliant and adding a frobitz tool to your Enterprise Schmebling System could do anything from nothing to breaking everything to actually turning your Schembler into a Frobitzer; the only thing you can count on is that whatever the effect, it's simultaneously the opposite of what the salesperson told you it would be and what you want (and in a stunning demonstration of non-transitive math, even if you want exactly what the salesperson told you, the way in which it's different from the promise is different from the way in which it's different from what you want)).

For the second question, I felt he committed the original sin of project management: he wouldn't deliver bad news. The point of CCM, if I understand it, is to make the project somewhat more efficient by being more honest and focused in accounting for risk. You can be more confident that the whole thing will be finished by the end of your buffer, but your visibility along the way is not radically better than before. It's better, because you have genuine fuzzy information instead of precise but false dates, but the only firm date you can expose is the last one. So if your client wants lots of firm dates, you have to have lots of little chains, which erodes the benefit of having a chain (which is, to reiterate, that pooling the risk for lots of little tasks into one shared buffer is better than baking risk, i.e. padding, into each individual task). But instead the speaker ran like a broken record on the script that, if you talk to your client (or vendor) about how doing it the old way you can promise them September, but with the new way you can maybe hit March but probably May or June. Which first of all doesn't make sense as an example, because why wouldn't you just promise June? But more importantly, in my experience it's not credible to promise great results from a new method. People who've been in software for a long time learn that it doesn't work that way. The best you can promise is transparency.

In order to maintain a PMP credential (Project Management Professional), you need sixty PDUs (Professional Development Units) per three-year period, which you can get by attending classes, writing articles, and various other means. While this gets warm bodies to show up for professional events, those warm bodies aren't necessarily eager.

In November I attended the Singapore Project Management Institute's annual Symposium, a one-day event taking up a few low-ceilinged, windowless rooms in the Suntec Convention Center. This was roughly as exciting as you would expect; as the keynote speaker said, "I know many of you want to attend just for the PDUs." I'll try to give you just the highlights in my notes.

• We started fifteen minutes late. Project Managers aren't any more organized than anybody else.
• There were over 300 people present; most were male and Asian, Chinese in particular. Of fourteen speakers, twelve were male.
• The keynote address was entitled "Project Management 2.0 and a Flat World". Ehhn.
• Idle thoughts during a presentation: there's a maxim that "you fall behind one day at a time". I wonder if that's really useful? Equally valid, it seems to me, would be "you fall behind a year at a time", which happens every time somebody drafts an unrealistic schedule.
• Gaah! IBM has seven levels of Project Manager, from Project Assisstant to Portfolio Manager.
• Do you have "T-shaped SSME" skills? "Every PM should have SSME skills in order that we are valuable employee for the new economy"
• A speaker, talking about consulting work for an Indonesian company, said that she couldn't give the key presentation herself as they needed to hear it from an ang moh.
• The merger of Chase Manhattan and Chemical Banks entailed 4000 projects for 58 units. The GANTT chart covered three walls of a conference room, and was used to prove to analysts that the merged entity would enjoy $1.5 billion in savings, which caused the stock price to go up. Not covered in the presentation: what savings actually materialized. (I'm too chicken! I should have asked)
• I have an entry in my notes for "MS Omega". I'm not sure if that's an actual software program from Microsoft, or a doomsday device.
• Lunch was excellent; any catered lunch that has a whole separate table for "Indian Vegetarian" has my love
• I did make an effort to talk to people. Everyone I talked to was there for PDUs to maintain their PMP, except for one person who works for a training company. I had lunch with a local telecom project manager, and never quite managed to understand what exactly he did. I also chatted with a Korean guy who works for a company that does telecom support for oil companies. He said he's done one trip to Nigeria, and it was very harrowing because the locals are cut out of the oil wealth and so target everyone associated with the oil companies.
• I am interested in doing some PMP training, not only for the $$ but also to help keep the material fresh in my own head, and also because, heck, teaching is something professionals in any field should do. However, that apparently will only be possible if Singapore changes the rules for student visas.

Overall, I didn't learn very much. I probably should have gotten my act together and proposed a presentation of my own, either on using Open Source (not very PM-specific) or how to incorporate Agile techniques without swallowing the full pitcher of Koolaid. Next year.

Here's the photo album. That's my balding head in the second and sixth pictures.

The tagline of PMI's magazine, PM Network, is "Making project management indispensible for business results.®". Let's leave off the meaningless "business results" verbiage and focus on the really egregious part of this: "making project management indispensible."

My objection isn't the indispensible part. I wholly believe that management, like politics, is a basic element of all human endeavors. And in fact, management is even more pervasive than politics: you can escape politics if you are a team of one, but you'll still have management needs. It's true that many projects don't have project managers, and still succeed, but that doesn't mean they didn't have management. If you are going to get groceries, you will (in America) go to your car, drive to the store, collect groceries, pay for the groceries, come home, and put the groceries away. If you do those tasks out of order, you will have problems. Even in the routine task of getting groceries, de facto project management is occurring.

My point is that project management already is indispensible. A tagline of "pointing out that project management is indispensible and that employing a qualified project manager is, in many circumstances, going to help you out a lot" would be (if only it fit on the maganize) a great tagline. But to state that we have to make our skills indispensible is awful for two reasons:

First, it suggests that project management is not already indispensible.

Second, and far worse, it says that Project Managers are people who, even though you don't need them right now, are damned well going to make you need them whether you like it or not. It's a marketing tagline in the worst way - it's about creating demand for our services, regardless of whether that demand is genuine or not. Yuck and double-yuck.

Several years ago, as I was coming up on ten years of experience in project management, I decided to obtain professional certification. My reasons included a desire for professional growth, to interact with peers, to receive and in turn transmit knowledge, building contacts, and of course the cynical potential of personal gain. A bit of research confirmed that the Project Management Institute, which I'd heard of before, remained the 800 pound gorilla of the field. They offer the "Project Management Professional" credential, or PMP, which requires a college degree, 4500 hours and 36 months of project management experience, 35 hours of classroom training, and passing an exam.

In a series of upcoming posts, I will describe my experience with the PMP in detail. I will try to answer questions such as, Is the PMP helpful for employers? Is the PMP helpful for project managers? How practical is the knowledge covered in the PMP exam? How hard is the PMP exam? How well does the PMP satisfy its goal to "advance the project management profession and to recognize the achievements of individuals"? How well does PMI "promote a unifying influence in the advancement of Project Management"?

To start things off here in part 1, I'll summarize the controversy I saw surrounding the new exam released in 2005 with the Third Edition of the Project Management Body of Knowledge guide, or PMBOK.

---

I started thinking about getting a PMP in late 2004, but didn't do much research until early 2005. I discovered that a new version of the exam would be rolled out in September 2005. But before you can take the exam, you have to have 35 classroom hours. One option was to take a class at one of the local universities. San Diego State University and University of California San Diego both offer PMP programs, which are one or two-year affairs with a total cost in the range of $5,000 to $10,000. However, you can take a single class and pay in the neighborhood of a thousand dollars. But, it turns out that the San Diego Chapter of PMI offers specific Exam Prep classes that provide the required number of hours. And, because they are taught by volunteers who are themselves PMPs (seeking the 60 Professional Development Units, or PDUs, that PMPs must accumulate every three years to maintain certification), the classes cost only about $400.

The summer classes coincided with my annual July Vancouver vacation, which ended the chance of taking the old version of the exam. So I signed up for the fall class, six full-day Saturdays in a row, and after completing the classes registered to take the new exam in early 2006. During the class, many students were quite nervous about the new exam, and I found out why: The previous exam required 141 correct out of 200 questions, or 70%. The new exam still had 200 questions, and still required 141 correct, but 25 of the questions would be present solely for "testing the test", and would not count towards correct answers. So, on October 1, 2005, not only did all the questions change from "second edition" to "third edition", but the passing score rose from 70% to 81%.

Rumors passed around class included that the summer classes had forty or fifty people (we had about 12 regulars), that all available test slots in the San Diego area had been booked for months before the cutoff date, and that some students had flown to Nebraska and other underpopulated mid-West states solely to be able to take the old exam before the cutoff. The instructors said that this was part of an effort by PMI to "raise the bar" for new PMPs and make sure the credential didn't get diluted. As the class continued into OCtober, I heard more rumors, both from within class and without, that the percentage of test-takers passing the test on the first try was plummeting from 70%+ to 40% or even lower. (The test costs $405 (for members of PMI, itself a $119/yr cost, plus $10 for application and $30 for the local chapter), and $275 for re-takes.)

Eventually, I received an PMI email—not from PMI, but forwarded from an early test-taker:

...Before offering the new examination, PMI assembled a group of volunteers to help establish the passing score. Using a method known as the "Modified Angoff Technique" (a proven exam development method), a group of global PMPs in the summer of 2005 assessed each test question and independently evaluated the questions to determine their difficulty level. Their responses were then sent to PMI's psychometric (exam development) experts and averaged. From that information, PMI?s psychometricians recommended that PMI adopt a passing point of 81 percent (141 correct questions).

... After performing a statistical analysis of [actual test results], PMI and its independent psychometricians were able to make conclusions about the performance of questions as well as candidate performance ... PMI revised the passing score for the exam to 61 percent (106 correct questions). PMI then applied the new passing score to all examinations taken since 30 September 2005 by candidates who sat for the new exam. PMI is in the process of updating the candidates' records.

While we remain extremely sensitive to candidate and trainer concerns about such a change in the passing score, these considerations must be weighed in context of the overall purpose of the exam: to provide a consistent global standard that all practitioners must meet to ensure the credential is awarded to qualified individuals. ...

PMI understands that the changes to the exam and its passing score raise
numerous questions. ...

—forwarded email from Drew Ihlenfeld, PMI

It's hard to see such a drastic rescoring of the exam as anything other than a major failure of the exam development process. Of course, the retroactive rescoring effectively corrects the problem, but that's after-the-fact quality control, and it means that their before-the-fact quality assurance failed. And it doesn't address the wear and tear on PMP applicants, both those that were temporary failures and all of us in the months before and after the transition that had to make decisions in an atmosphere of uncertainty. For example, the email was dated 30 November, but it was weeks later before anything about it was posted on the website.

In the event, my classmates and I were very relieved to learn of the change in scoring, and I finally took and passed the exam on April 1, 2006 with a score in the high 70s. Nonetheless, I was somewhat bemused to recently read PMI's version of the fiasco in the 2005 annual report:

As part of best practices for exam development, PMI proactively reviewed data collected on the revised Project Management Professional (PMP) certification examination.

Driven by a role delineation study identifying volunteer-credentialed practitioner recommendations on how the skill sets for a PMP had evolved, PMI conducted this evaluation and revision based on the Institute's desire to accurately provide a consistent global standard that ensures the credential is awarded to qualified individuals, and meets the needs of PMI's stakeholders. Specifically, the attributes to "lead" and "direct" were identified as key elements of a more mature PMP.

PMI utilized proven examination development methods in revising the PMP examination, and conducted all appropriate due diligence to assess the applicability and difficulty of each test question as determine the overall percentage passing point.

Quality control measures implemented prior to and following the exam launch data indicate the exam is functioning as designed, including the fact that no inaccuracies in scoring and no malfunctions in the test's administration or its translations have occurred.

—PMI 2005 Annual report, p 23-24

I'm pleased to announce that, after some study, a fair amount of paperwork, more than one outlay of cash, and a four-hour-long multiple-choice test, I am now a certified Project Management Professional. I was motivated in part by my belief in being professional about my job, and that entails continuing education, communication with other people in the same profession, teaching, and all that other good stuff. The Project Management Institute is the 900 pound gorilla of professional organizations in this line of work, incorporated in 1969 "to promote a unifying influence in the advancement of the field of Project Management ...." I'll have more to say about that, and about the certification process, in a later post.

The other part of a professional certification is of course its utility in hustling for jobs. So, if you know anyone—especially a non-profit— in need of the services of a certified project manager, be it a Technology Needs Assessment, Requirements Development, Usability Testing, or general-purpose Managing of Projects, drop me a line.