Project

"The flower in the vase still smiles, but no longer laughs" Malcolm de Chazal

Aphorism week continues through Friday

Yesterday's article on the proposed PMI Practice Standard for Scheduling got me thinking about what value there is in complying with their standard. Is it better to include everything but the kitchen sink? Is it not?

Samuel Butler says:

Life is the art of drawing sufficient conclusions from insufficient premises.

Hmmmm...

Aphorism week continues through Friday

Just got an email announcing that the PMI Practice Standard for Scheduling is open for comments and recommendations. This would expand on Chapter 3 of the Guide to the Project Management Body of Knowledge (PMBOK). I think this is a good thing, but I'm a bit worried that it is becoming more and more prescriptive rather than descriptive. It is pointed out in one of the screens you need to pass through to gain access to the document that the PMBOK and the practice standards are intended to be "standards". In other words they are intended to be THE WAY that things should be done. This is a change from the original purpose of the guide to the PMBOK which was a taxonomy or map of the entire body of project management knowledge.

I have not completed my review of the document yet, but I have some concerns about the narrowing of scope which takes place in the development of documents like this. For example, this quote:

"The first step in the schedule development process is the selection of an appropriate method. Some organizations have chosen to standardize on a specific software tool. In this case, the scheduling method decision has already been made and does not need to be made again. Since it is the most commonly used method, this Practice Standard focuses on CPM."

If we look at what is said, the most commonly used method (CPM) has become the defacto standard and this decision "does not need to be made again". Further, the standard takes this assumption and quanitifies it as the baseline against which a schedule "conformance index" will be calculated by an outside auditor. The standard sets out a number of "required components" which are to calculate a score. It is interesting that the score is based on presence or absense of components rather than the quality. To quote from the proposed standard:

"If the particular required component and any associated must good practice are present in the Project Schedule Model then a single point is earned. Of note, all of the points associated with the required component must be earned before an assessor can record a conformance score."

It seems to me that this approach is less than ideal. In my opinion, the quality of the schedule is not based on some number of points on a per feature basis, a system where resource loading can be traded off for some different aspect. The quality is something to be assessed holistically. A spare schedule can be quite good while a schedule with a great deal of bells and whistles can obscure the truth. The fact that the assessment is based on the use of straight CPM scheduling leaves little room for innovation in an area which is long overdue for some new thought. But who knows, perhaps it is time to open shop as a schedule auditor and count the number of hanging activities...

If you are interested in reading it - to draw your own conclusions, and commenting on it - to better it, then here is the letter introducing the standard with all the information you need to access it. I'm interested in making it better. I hope many of you are tool.

Please review and comment on the exposure draft of the Practice Standard for Scheduling.

PMI plans to publish an update to the Practice Standard for Scheduling in Quarter Four of this year. The exposure draft is now available online for your review and comment by Tuesday, 15 August.

PMI both needs and appreciates your effort to thoroughly review the draft and submit recommended additions, deletions or corrections. We especially seek the input those who may be experienced or interested in scheduling.

Project scheduling is the delivery of the project scope over time as defined by the project team. The standard describes the elements and generally recognized good practices for schedule development and is intended for practitioners that are familiar with the fundamentals of project scheduling.

The Practice Standard for Scheduling will be one of PMI’s most important new publications. It was developed to reflect the latest in current practice and to align with A Guide to the Project Management Body of Knowledge (PMBOK® Guide)—Third Edition and other updated and new publications.

PMI members and nonmembers alike are invited to review and comment on the exposure draft. Please forward this message to others who may be interested. The link to the online exposure draft is: https://secure.pmi.org/exposuredraft/

Comments are due by Tuesday, 15 August. For more information, e-mail PMI Standards Project Specialist Nan Wolfslayer or call her at +1 610-356-4600, extension 5020. Thank you very much for your time and participation.

It is aphorism week here at Project. Too hot for anything else.

"Everything that is written merely to please the author is worthless" Pascal

"Experience is the name everyone gives to his mistakes" Oscar Wilde

Feel free to suggest your own favorites.

At a certain point projects get too big for some people and they just can't handle it anymore. One example is Windows Vista which has slipped extensively over the past year or so. And to the people on the inside (and to any number of people on the outside) the slips have not been unexpected. Philip Su, who was involved deeply in the development writes:

They knew months in advance that the schedule would never work. So they told their VP. And he, possibly influenced by one too many instances where engineering re-routes power to the warp core, thus completing the heretofore impossible six-hour task in a mere three, summarily sent the managers back to "figure out how to make it work." The managers re-estimated, nipped and tucked, liposuctioned, did everything short of a lobotomy -- and still did not have a schedule that fit. The VP was not pleased. "You're smart people. Find a way!" This went back and forth for weeks, whereupon the intrepid managers finally understood how to get past the dilemma. They simply stopped telling the truth. "Sure, everything fits. We cut and cut, and here we are. Vista by August or bust. You got it, boss." (source: http://blogs.msdn.com/philipsu/archive/2006/06/14/631438.aspx

Of course this is not just confined to Microsoft. A look at some of the recent events in the world will bring up any number of situations where a top down version of the truth is imposed upon a certain initiative or action with predictably unsatisfactory results. I have observed similar behavior with large development teams being exhorted to achieve the unachievable through methods which seem laughable in retrospect. I've seen situations where the project managers are squeezed between lying to their bosses and lying to their teams.

What do these situations have in common? Well, one common factor is size. With size comes heirarchy and with heirarchy comes a certain distancing from the reality of the situation. This gives more room for those at the top to believe that their desires actually can influence what the results are. In a smaller group, people are quickly deposed of this fiction as they can see the effects or lack of effects on the team.

Another common factor is that the size is frequently bigger than anything they have done before. Here size is shorthand for a host of things such as complexity, team size, geographical size, duration etc. The skills and behaviors that worked with smaller teams and smaller projects just start to run out of steam. They don't always scale up. It isn't that they couldn't scale up, but rather I think that the issues of scaling up are not taken into account. People take their previously successful tactics and try and make them work. Nothing wrong with that. One rule of successful projects is to minimize risks. One way of minimizing risks is to minimize change. Or at least it minimizes risk except in cases where change is required. The unfortunate truth is that big projects sometimes do require change.

Now is the point where project managers of superprojects jump in and say "In my industry ..." and cite a methodology or process or mindset or all three which does work on big projects. And the response is "great but" and goes on to argue it is a bit heavy for small projects. This can echo back and forth for a while. But it would be just a lot easier if people would just acknowledge that the skills and processes and the people needed on a big project are a bit different than those on a smaller project. Ignoring this is a cause for failure. Pants too small rip embarrassingly when you bend over too far. Pants too large drop at inopportune moments. My only point is to think about these things in advance and if possible try them on before you buy. If you can find a good tailor then go that route. You just don't want to end up in a situation where you are asking the team "does my butt look big in these?" and expecting to get good data back from them.

In a quiet summer the PM world is buzzing with news of a new PMI certification. Moving beyond the territory of the PMP (Project Management Professional) the Program Management certification would be for those who are leading programs. The role of which is defined as:

• Program managers are responsible and accountable for the coordinated management of multiple related projects directed toward strategic business and other organizational objectives. These programs contain complex activities that may span functions, organizations, geographic regions, and cultures. Program managers build credibility, establish rapport, and maintain communication with stakeholders at multiple levels, including those external to the organization.
• Program managers define and initiate projects, and assign Project Managers to manage cost, schedule, and performance of component projects, while working to ensure the ultimate success and acceptance of the program. Program managers maintain continuous alignment of program scope with strategic business objectives, and make recommendations to modify the program to enhance effectiveness toward the business results or strategic intent. Program managers are responsible for determining and coordinating the sharing of resources among their constituent projects to the overall benefit of the program.
• Program managers possess the knowledge and skills needed to be effective in both the project and business or government environments, and to make decisions that accomplish strategic objectives. In addition, the program manager should have advanced skills in finance, cross-cultural awareness, leadership, communication, influence, negotiation, and conflict resolution.

The certification process would be fairly similar to the current PMP process with an initial experience and education assessment and a multiple guess test. But the new twist is the third step:

"The third competence assessment occurs through a multi-rater assessment in which a team of raters that the candidate selects will be evaluating their competence in a work environment to perform germane tasks of a program manager as defined through the examination specification."

OK PMI, now I'm even more confused. I can vaguely see the value of the PMP certification. It attests to a basic amount of training and experience. The CAPM is sort of like a spelling test. Both are targetted at job seekers it seems to me, and may have some attraction as a sort of outsourced Project Management skills assessment for organizations which are incapable of determining the relative skills of their own employees. I can see some value in that. But this new cert seems to be targetted at fairly high level people. If we make the very crude analogy that the PMP certification is the equivalent of other professional licensing such as Certified Public Accountant (CPA) or passing the Bar examination for lawyers, or professional registration as an Architect or Engineer, then what is the equivalent of the new Program Manager cert? It would be something like being promoted to partner or some other sort of job title.

In the professional organizations I'm familiar with, that sort of promotion is based on performance and experience, not on passing an examination. Program management is not just something that you come in at entry level and do. I'd be worried to work in an organization where program managers are selected based on whether they have or do not have this credential. It would mean that their means for evaluating competence are broken.

But with all of these sorts of things, the market sees things slightly different than I do, and they value the present certifications more highly than I do, so just watch this one take off. And of course watch as PMP's start to scramble to get a few more initials printed on their business cards, and PMI pulls in another $1000 a piece and the Rita Mulcahy's of the world buy a cheetah skin stole.

For the official FAQ on this go to PMI's website here

Yes, I know, the book "Freakonomics" came out YEARS ago. But I am just reading it for the first time. There are several things I like about it.

It is at its heart an ode to skepticism. In my opinion this is a worthy thing. There are many things which are unexamined in this world and it seems to me that the foundations of many critical issues often go unexamined. Sometimes they are clouded in mystery intentionally. Being able to cut through this and see clearly what the real relationships are is an essential skill, and the first step in learning it is to understand that it is possible. This book gives some examples of where it is possible and reveals some of the value in doing so (catching cheating teachers, placing your attention on real rather than supposed risks ...)

The book also provides some realistic examples of how causation and coorelation are two different things. Breaking the two apart is the first step in removing superstitious behavior and moving beyond just trying things which might have worked before in a different situation. Even with the very light treatment given to the statistical methods used, the book points out that it is something which is possible and something that can be valuable to examine. This sort of critical thinking is the biggest defense against the propaganda which I find is increasingly common in the world.

The biggest failing I see in this book is that it fails to point out the real heart of the "thinking" method that Levitt uses, a critical examination of the model that is being used. Time and time again he talks about analysis and conventional wisdom, but fails to make the connection that conventional wisdom is based on an incomplete or incorrect model of realities. He also fails to point out the possible errors or inevitable omissions in his own models. Analysis is nothing unless your model is constructed correctly. And all models are abstractions to one degree or another. Skillfully building those models and understanding the factors which influence behaviors is a skill which is in short supply and which results in any number of bad decisions. Of course, it is impossible for a single person to question everything and build a model to support all of their thoughts, but it is possible to show people how that models posed by others should be examined for veracity and completeness. Spending a bit of time on the fundamentals would be worthwhile in my opinion, though it might make it much less of a quick read - something the millions of readers of this book certainly appreciate.

OK, I just lied. The biggest failing of the book iin the presence of the insanely effusive paeans to Levitt's big brain which are interspersed with the chapters and are plastered all over the dust jacket. Things like "Levitt is considered a demigod", "The most brilliant young economist in America" and "Steven Levitt has the most interesting mind in America" litter the pages. Why? Shouldn't the work speak for itself?

Not sure if the other project management writers are on a permanent vacation or not, but I haven't seen much in the way of new work in the past month or so.

Personally I've just been resting on a branch waiting for the winds to start blowing again.

In the mean time, if you are bored, take a close look at the bugs.

Yes, along with multiple undo, the ability to format cells with a background color and pattern will be here in Project 2007 which has an expected release date sometime in early 2007. The Beta2 release was yesterday and a new SDK was released (find it here).

I'll be working through this stuff over the coming weeks, but some of the best things are the simple ones. For example this bit from the table of VBA Object Model Changes:

Cell, CellColor property, CellColor as PjColor

New for Cell object. Background color of the cell. In Project 2003 as GroupCriterion property only.

Cell, FontColor property, FontColor as PjColor
New for Cell object. Foreground color of the cell font. In Project 2003 as GroupCriterion property only.

Cell, Pattern property, Pattern as PjBackgroundPattern

New for Cell object. Background pattern of the cell. In Project 2003 as GroupCriterion property only.

Global, Application Font method Boolean Font(Optional Variant Name, Optional Variant Size, Optional Variant Bold, Optional Variant Italic, Optional Variant Underline, Optional Variant Color, Optional Variant Reset, Optional Variant CellColor, Optional Variant Pattern)

Changed: added parameters CellColor and Pattern.

See that? Cells have colors and patterns. Welcome to 1995! Now to install the beta and see if we are still limited to 16 colors...

PS: Don't take the 1995 comment too harshly. From the other new things in Project Server 2007 it is clear that the team has focused on solid improvements to functionality

This probably belongs on my other site (http://zo-d.com/stuff/) but I haven't added anything here for a while...and I want to keep my readers entertained. Anyway, apparently someone has invented a sort of pied piper for cockroaches. A tiny robot doused with cockroach pheromones which can dare the other cockroaches into outrageous (for them) behavior. The article can be found here; http://www.newscientisttech.com/channel/tech/dn9136.html. The first thing that came to mind when I read this was human teenagers...

Lidiane's Microsoft Project 2007 Blog announces some of the new templates to be included in Proj 2007. From the titles you can see that the targets are getting deeper into HR, Marketing, IT and Legal areas. I hope these templates are more useful than the ones in earlier versions. My opinion is that they are so basic that they might almost be dangerous - dangerous in the sense that an inexperienced user might mistakenly follow them line for line. But, I'll not talk anymore about that. I'm an inexperienced users with many other software tools. Here is the list so far announced:

• Annual Report Preparation
• Develop Skills Needs - Hiring Plan - Hiring Forecast
• Finance and Accounting System Implementation
• Human Resources Information System Implementation
• Marketing Campaign Planning
• Marketing Event Planning and Execution
• Performance Reviews
• Request For Quotes (RFQs)
• Vendor Request For Product Development Planning
• Product Evaluation Post Launch
• Six Sigma DMAIC Cycle
• SOX Compliance and Technology Options
• Strategic Merger or Acquisition Evaluation
• Vendor Evaluation and Consolidation
• Customer Feedback Monitoring
• Financial Service Offering Launch
• Internal Readiness Training
• ISO 9001 Management Review
• Managing Incoming Proposal (RFP) Solicitation

Eric Landes has a brief code snippet on using C3 to automate project here:Corporate Coder : Project 2003 Adding Tasks via C#

All I can say is that C# is slightly less than elegant in the way it handles optional parameters.
For what an idea of what I'm talking about, here is how to invoke FileOpen:
m_ProjectProApp.FileOpen ( "MyProjectName", missingValue, missingValue, missingValue, missingValue, missingValue, missingValue, missingValue, missingValue, missingValue, missingValue, PjPoolOpen.pjDoNotOpenPool, missingValue, missingValue, missingValue, missingValue);
Just a bit awkward, wouldn't you say?

Treb's blog notes that there are a couple of interesting webcasts coming up.

The first is an overview of Office Project Server 2007, presumably covering what you need to know about how all of the server and client processes tie together. The description states:

"Microsoft Office Project Server 2007 has a new architecture, enabling the system and solution to provide new functionality and capabilities. This webcast provides an overview of the architecture of Project Server 2007, and looks at how the new system functions. We also examine how Project Server 2007 differs from Microsoft Office Project Server 2003, and identify where developer opportunities exist."

You can register for it here:

Architecture Overview of Office Project Server 2007 (Level 100) Monday, May 08, 2006 11:00 AM Pacific Time (US & Canada)

The second is a Project 2007 Preview:

"This session is not your typical Deep Dive--it's a preview of what's coming in the next version of Project (P2007). Discussion will center on new features in P2007 and a focus on planning for resource management - planning your organizational needs, and best practices for decision making regarding resources.

The Project Deep Dive Series is meant to provide an in-depth look at current business topics that most affect Project Managers/Directors and how to leverage Microsoft's tools and project management best practices to effectively address these topics."

Register for it here:

Project 2007 Preview Tuesday, May 23, 2006 10:00AM Pacific Time (US & Canada)

I think that the Architecture session hosted by Larry Duff might be the more interesting one, but try them out and see. You can always keep it on in the background if it gets boring. One thing is certain and that is that Microsoft is trying to get deeper into the world of work and trying to get better integration with other apps.

At least in my opinion it is not Microsoft Project. I'm starting to think that trust is the most valuable tool in the Project Manager's bag. I'm not sure where talks about that in the PMBOK though. The more uncertain part of Project Management is the people side of things. I'd go on, but time is tight. Let me know what you think is most important contributing factor to a successful project.

Hard to believe 100 years have gone by. My Grandfather witnessed this one just across the Bay in Oakland, but the smoke from the fires in San Francisco (the major cause of damage there) was probably just as visible as the Oakland Hills fire was from San Francisco. Here are a couple of documents from that era. (click on image to see a larger version) The first a notice that Police and troops have been authorized to "KILL" looters:

And the second, one of the panoramas around the area of City Hall.