Thursday, December 11, 2008

Begging for feedback - project close

I've talked to PMs recently who are almost literally crying for feedback from their project teams in order to improve and still get nothing. In organizations with project post-mortem procedures, not reviewing the lessons learned and estimates vs. actual data to come up with recommendations and revised practices for future projects is a terrible waste.

Perhaps because many project teams are eager to be done and move on to the next project, the process is hard to manage. When it is being done, it may be that many organizations feel good about having done the close work and then forget that review, analysis and follow-up is required to get value out of the closing process. Depending on the organization's culture, the issue may be a resistance to change inclusive of any data that indicates a need to do things differently.

I digested this and then looked at my department's own processes for closing a project (which I mostly designed...). I realized we are pretty much guilty of not systematically looking for process improvements out of our documented lessons-learned. So here's what I am going to do about it:

1) Add a section to our SharePoint portal where all lessons-learned will be posted for department access. This way they are not buried in the close documents, but rather are on a searchable project management site.

2) Propose a quarterly review and write-up of trends and findings from this information and hopefully publish it to the department, better still all PMs in the company (informally).

3) See if we can facilitate this partly through a quarterly project management retreat where we can concentrate on this stuff and really get into why certain things are happening and what the root causes are.

Focus on a different problem that one of my colleagues from another area shared with me: How to get project team members to offer honest feedback on project manager performance. This colleague is new to project management and hungry for feedback on ways to improve his own PM performance as well as the practices he and his department use to execute projects. His frustration comes when team members offer little or no feedback for improvement when he knows from the project's performance that there are many opportunities.

His post-project completion lessons-learned sessions are not yielding the feedback he needs and wants, so he's trying to figure out other ways to get this. Possible obstacles:

1) Team members uncomfortable offering feedback in public settings - perhaps offer anonymous surveys.

2) Sense that the culture is too deeply ingrained for any changes to take place - seek executive sponsorship to drive real process improvements tied to cost savings and time-to-market speed.

3) Inertia... "we've always done it this way"... comfort. This is hardest to overcome. He'll have to get people to see the value and want to change their PM practices.

He's passionate enough to keep after this even in the face of slow progress. It's worth doing, because it will help us get new products to market faster.

Monday, November 10, 2008

Rescheduled - Me at NEW-PMI - March, 2009

Due to the big storm on December 9, NEW-PMI (thankfully!) canceled their chapter meeting and rescheduled me to present on March 10 in Green Bay.

So - If anyone happens to be in Wisconsin's Green Bay area, I will be presenting to the Northeast Wisconsin PMI chapter on March 10. The topic is effective time management for project managers in a multiple project environment. I helped found the NEW-PMI chapter back in 2002 when I lived in the area. It's a great, fast-growing chapter.

Hope to see you there!

Thursday, October 16, 2008

Cool PM Stuff I am up to...

Outside of the regular gig, my life as a PM educator and academic is very exciting, as follows:

In October, I am teaching a 2-day project management seminar for the State of Wisconsin's Enterprise Leadership Academy through University of Wisconsin - Madison.

In November, I'm scheduled to teach a 2-day project quality course at UW-Milwaukee.

I'm also reviewing and developing some courses for University of California - Irvine and am going to teach an online course for them next spring.

At UW-Platteville, I am teaching a course this fall in their MSPM program and am scheduled to teach two courses in Spring.

I am teaching Managing the Project Team in Lakeland College's MBA program this fall and will teach a project procurement course for them in the spring.

On the PMI front, I will be doing two SeminarsWorld dates in 2009. PMI also invited me to speak at the 2009 Asia-Pacific Global Conference in Kuala Lumpur. I am hoping to get a SeminarsWorld for this conference as well.

And, perhaps most cool, I just got word that I am one of the 2008 recipients of the PMI Dr. Harold Kerzner Scholarship, sponsored by International Institute for Learning. I plan to start my doctorate studies yet this year, most likely through the University of Management and Technology in Arlington, VA.

Redefining project success - more on the value of the Triple Constraints

On the various PM web sites and blogs I follow, especially on gantthead.com, there are lots of PMs writing about redefining what project success means. I've seen some fancy multi-dimensional models offered for looking at defining and measuring project success. Nearly all of these are looking at the deliverables post-project rather than measurement of success during executing and controlling.

Here's my reaction to most of these:

Let's not get so bogged down in redefining post-project success parameters that we forget to manage live projects.

On time, on budget, within quality expectations, and all agreed-to scope delivered remain the critical measures of success during the project's lifecycle. Post-project measures, I offer, should not be as much of a concern to the project manager as are the live project measures. A hokey analogy: Whether or not the customers like the aircraft you just delivered is immaterial if you don't land the thing successfully.

Use your basic and proven measures to bring the project safely and successfully to completion. After delivery, the sponsor and stakeholders can subject the project to further measurement of whether it meets objectives and fulfills the business case that got it approved.

Wednesday, October 8, 2008

The Holy Grail of Project Management Process and Methodology

I recently did some consulting for a high-tech division of a very large company (I'm under NDA, so that's as much description as I can give). The focus was on providing a base level of project management training while getting an idea of the unique project management challanges they face.

During a roundtable discussion during lunch, I was able to hear from the division's VP, key operations exces and managers, and product development staff, marketing staff and engineers. While the issues were framed in the context of their specific environment, the essential problems are ones I (and probably you) have observed and experienced throughout my project management practice and teaching career.

The senior managers responsible for delivering projects want project management processes applied to ensure successful project delivery and to provide accurate status reporting on projects. Those managing the projects really want to do this for themselves as well as for their bosses.

Senior executives want this information and want their organization to efficiently deliver projects.

But... No one wants to do any extra work to develop and execute on project management process... because, see, we have all these projects. And, the operations/production people, while seeing the value of project management, also see themselves as tough, pragmatic managers who choose not to add project management "overhead" to their jobs of getting products manufactured and process improvements in place. You know, getting real work done.

What's a project management advocate to do? If everyone acknowlwedges the need and value of project management to helping the organization deliver projects more efficiently, but everyone is too busy to execute project management, how do you get out of this loop? How do you win over the operations types who feel that project management does not add value to cranking out widgets?

The Holy Grail: Figuring out how to bring the most impactful, valuable components of project management to the organization while focusing on suppressing work perceived as overhead to make it happen. Some of the high-value examples are so simple, basic, yet meet with resistance.

My favorite is the tracking of actual versus estimated hours used on project tasks by human resources. There is no more important metric to track than resource actuals. The additional metrics and reporting this step enables both tactically and strategically are legion, yet this basic project management function meets with tremendous resistance, even in some organizations that are doing many other standardized and robust PM practices. Why?

This step is, depending on the organization:
Perceived as extra work, considered too detailed or granular, labeled as "big brother is watching", and more...

In one project management class I was teaching a few years back, a participant said something along the lines of not being able to ask "professional people" to account for their time. I collapsed with disbelief and laughter. My first question was "you are paying these people, right?" Seriously, in this day and age no one collecting a paycheck should be questioning efforts to understand how their time is spent, especially in the context of getting better at projects.

This is just one example of many components of project management that could provide incredible value to organizations but meet with resistance because of perceived difficulty to implement or perception of overhead. Champions of project management must find that elusive Holy Grail - that balance of value versus detail and process.

With tracking actual resource hours, the project management advocate must: (1) find a cheap and easy tool to use (2) figure out the largest increment of time to track that will still add value to the project management process (3) sell this as a way to track projects and help build the organization's database of estimating resources, and certainly not an effort to see how people spend their time.

Another great example is the project charter. This is one of the most important documents in all of project management practice. Yet, it is surprising how many projects get launched in organizations of all types and sizes without a single, simple document that captures who launched the project, why it was launched and what it is supposed to achieve. The project charter is another low effort, high-value step in adopting basic project management practices.

Simply documenting why a project was launched, who is responsilbe for paying for it, managing it, and tracking how much time has been spent on it are low effort, high-value project management tools that will pay dividends fast. The important thing with the charter is to keep it brief and simple. 2 - 3 pages is enough detail to document what is supposed to be delivered, how, when, by whom, etc, but not so much that anyone can claim that it is too much overhead to write it.

Are these two examples the Holy Grail of project management? No... but you can make a strong business case against anyone who thinks it is overhead that doesn't add value by showing how little effort it could take to put these couple of basic items in place. That's the Holy Grail - high-impact, low-overheard project management process improvements that help the organization, improve the perception of project management, and, in the words of John Belushi in Animal House, "don't cost nuthin."

Friday, August 1, 2008

Doing the Right Thing, What's Happening August - December

Doing the Right Thing: In teaching my UW-Platteville course for their master's degree in project management program this summer, I've had the opportunity to review the project journals of over 20 students, all telling stories about live or recently-completed projects on which they were either the PM or a team member.

My observation from this work is almost certainly not original, but is still striking to me anyway: In project management, general business, and indeed, life, I think nearly everyone can quickly determine the Right Thing to do in a specific situation. Where we usually get hung up is with all the personal, psychological, organizational and environmental obstacles to actually doing it.

As we all know, so much of project management is communications. A colleague of mine often refers to The Conversations - those often-difficult conversations that one must have with sponsors, stakeholders, team members, vendors, etc. in order to do the Right Thing within the context of a project. Actually having those Conversations is far harder than one might think for many project managers. Concerns about job security, being liked, respected, reporting structure, and other factors influence whether and how the conversation occurs.

So, perhaps more project management training needs to focus on how to actually do the Right Thing - how to have the conversations, how to do an honest self-assessment prior to going into a potentially difficult situation, how to debrief one's self after a difficult situation, and how to get better at handling these. As PMs improve their tactical ability to actually do the Right Thing, we'll see more projects get completed within traditional and non-traditional definitions of success.

I am looking at a busy August - December outside of my day job: I am doing a couple of days of consulting for a firm in mid-August, presenting at a conference in September, teaching for UW-Madison in October, UW-Milwaukee in November, and teaching a semester-long course for UW-Platteville this fall semester. I am also scheduled to present at a couple of PMI SeminarsWorld in 2009, and have papers submitted for the Asia-Pacific Global Conference in Kualu Lumpur in February. Stay tuned...

Wednesday, June 25, 2008

Triple Constraints Under Attack!

There's been some discourse recently on project management sites about whether the venerable Triple Constraints are still valid measures for determining project success. Here's a few thoughts:

First, they are not measures for success as much as they are parameters for project planning, scheduling and control. There is still plenty of value in using this model as a way of communicating to project sponsors and stakeholders that the constraints influence project decisionmaking and tradeoffs.

The Triple Constraints do not influence the quality or validity of the project's business case. Nor due they on their own take into account the fact that a project can be late and overbudget and still be perceived as wildly successful.

The triple constraints are just tools. They are valid in helping the PM and sponsor shape basic planning, scheduling and control issues and problems. However, these are not true measures of project success. A project can deliver on all three as well as agreed-to scope (which, by the way, is represented by the size of the triangle - don't tell me otherwise, I will argue with anyone on this forever!), and still be a failure if the business case was not valid or changed mid-project, or if the end users are unable to use the perfectly-executed project deliverables.

New ways of assessing a project add dimension to the evaluation and planning processes. They also, however, raise the debate of the role of the project manager. I do not completely agree with the ongoing movement that posits that PMs should be justifying their projects, making their business cases, etc. That's the sponsor's job - the PM helps. This is where the additional dimensions of project success and evaluation can help all involved to do their jobs more effectively.