Electus Elucidations

I’ll have to elaborate on this further at a later date, but I wanted to quickly post an observation.  My current contract, which will remain nameless, is always asking for a simple status report.  The executives in this organization eschew learning anything new.  They want you to simplify things for them.  Rather than a simple, color-coded spreadsheet that reflects status and allows you to see relevant information, they opted for a nebulous, ill-defined letter grading system.

Here’s a picture of the still too simple MS Excel spreadsheet with checkboxes:

Here is what the executives would rather have:

In the spirit of simplicity, I propose we start giving status using my new methodology.  I call it “Triple S”

Triple S is short for “Simple Stick Figures”  Feel free to use this status reporting methodology the next time you have an executive who refuses to learn how to read a simple Gantt chart.  Use it the next time you have a client that tries to dismiss your efforts to improve ROI with a condescending statement like, “That’s too complicated.”  Then, be prepared to find your next contract. 

I don’t know why academics publish such arcane information that seems to be of little use in the real world.  I’m going to periodically publish reviews of articles here so that we can get some real discussion around PM concepts as they relate to managaing projects in the trenches.

I just completed an article from the March 2007 issue of the Project Management Journal, published by PMI.  This article was a joint effort between and experienced PM and a PhD candidate with a total of 1 year of IT experience.  Apparently 1 year of IT experience qualifies the person as a consultant.  I’m skeptical.

The article is titled, On Faith, Fact, and Interaction in Projects by Joana G. Geraldi and Gerald Adlbrecht.  Their premise is that the rise and fall of project complexity might follow a pattern that could be useful in, um, could be useful in, well, I don’t know why knowing this would be useful.

In the conclusion, they state, “The association of semistructured interviews with questionnaires enabled a better comprehension of the problems associated with managing complexity.  However, the pattern of complexity in itself has the potential to be a good indicator of the level of complexity in a project.”

Well, what great news!  We have the “potential” of having an indicator of the level of complexity in a project.  I’m struggling to know how to apply that to my projects.  It’s not new news that there are problems managing the complexity of a project.

I’d like to see more papers that talk about real world applications and quantitative analysis.  Paper after paper seems to follow the sociological model of qualitative research that depends solely on questionnaires, interviews, observations, and subjective conclusions.

I’ll report back on the next article.  For now, I don’t find anything useful in understanding that “complexity is complex!”

A senior VP came up to me and said, “Congratulations!  It looks like we are going to finish the project 2 weeks ahead of schedule!  Good job!”  As I looked at the plan, I had a question for an engineer who had been working on the project:  “Why are all of these tasks marked complete?  I didn’t know that we had already finished building this module in 5 days when it should have taken 20!”  I looked at the plan and sure enough, this person had booked all of their time to a single task for one week!

Have you had this happen in your organization?  On many occasions, I’ve had to do dance well in order to reset stakeholder expectations based on false reports from an inadequately executed project schedule.  Many would like to blame the tool for these kinds of problems.  I’ll hear from many business customers that MS Project is simply getting in the way.  The truth is that the organization’s training process is probably broken.

You see, the business world has progressed to the point that a basic competency in computer applications is expected at the time of hiring.  As a result, the company spends no time training new hires, contractor or otherwise, on their software platforms.  They fail to train on their operations processes or how that software is used.

This lack of training results in poor use of many powerful applications.  For instance, MS Excel gets used as a simple task list and calculator when proper use of all its functions could yield linear programming predictions, estimates using Monte Carlo analysis, and regression forecasting on a t-distribution.

In the opening story, MS Project is too often used as a task checklist instead of a project analysis tool.  If proper training on the posting of time had been delivered, the situation with the engineer could have been avoided.  The project schedule would have stayed in line and expectations for senior stakeholders would not have flown wildly off track.

When I’m called in to rescue a project, I suggest to companies that they first look at their internal business processes.  What about our daily operations process could have contributed to this schedule delay?  What about our training program could have let down new contractors we have hired?

When making assumptions of new hires for a project, a company needs to invest training time into those people so that they are familiar with how the company does business.  What terminology or acronyms are peculiar to this organization?  How should the new hire post time to MS Project?  What is the process for issue escalation?  What are the proper communications tools for posting progress?  Sometimes a new hire will start a new Google Group and collaborate with other project team members using this option.  How does the health care organization who has privacy concerns feel about that?

In mature organizations, the new hire should expect some modicum of training on how they use software in their daily business.  When this training is lacking, the organization is usually less effective, especially with new hires and contractors.  In this day and age of outsourcing and short term project teams composed mainly of contractors, training in an organization’s software use and business processes will go a long way to ensuring a productive engagement.

The next time a VP asks you why the project is out line, use it as an opportunity to educate.  Suggest a short training class on how to really use the software.

I’d love to hear your stories.  Feel free to post a comment.