Managing the Confusion - Teaching Project Management

It has been quite busy the last month which has prevented me from updating the blog till now. Actually, don't tell anyone but I'm supposed to be updating a PPT presentation that is due Monday.

Now unless your an accomplished teacher then this tale of my experience will be of interest to you. You see, the PPT presentation I'm supposed to be updating is the course content that I will deliver this upcoming Wednesday. I already have the content ready, and delivered it last month, but although full of PM wisdom, I feel that it didn't deliver a compelling message.

Yes.. there are lot's of people out there willing to provide their advice on how to make it better. Amidst the sea of free advice, I have one to share with you that I'm calling Managing the Confusion.

The premise behind "Managing the Confusion" is that people develop a fog in their brain that stops any information from sticking. Therefore you need to wipe the fog away from time to time if you want any new information to get in. The rate of fog build up is proportional with the amount of new information.

Fog Clearing:
Whoosh .. are you with me?? I just cleared any fog that was building up. Can you recall what you just read? I bet for the most part you can.

Now for the PPT (PowerPoint) approach. Clearing the fog needs to be done every three slides of so. The exercise doesn't need to be anything more that asking the audience what they learned. I find that if you can get them to move, then that stirs up the blood flow to the brain.

Whoosh... still with me.. great..
Another exercise is to re-establish what your telling them about. So come the third slide, start off with ... And here we are going to discuss...blah blah (keep the blah blah short) and then go right into.. and what do you think about this..

The gold comes from if you can get the audience to tell you things that you were going to tell them anyways, then when the next couple of slides come up you can say things like .. see, you already know this stuff..

Other points: Keep the slide content crisp and concise. Don't worry too much about expressing the wisdom of the ages.. they will feel much more satisfied by having an engaging experience rather than a class lecture. You will get the opportunity to express the wisdom of the ages if the audience is willing and interested... which will come about as they direct the content, not you.

Good luck..

Project Measurements - Real Data

Ok.. I'm back from sorrowful land. Time to give you an update on the progress towards implementing the Project Performance Index measure.

I'm pretty set now on the three measure categories (Business Performance, Project Performance, and Team Performance). And so far most of my clients have been willing participants to allowing me to solicit their opinion (about their own performance). One client (actually the VP Sponsor) wasn't too interested in me surveying her hot bed project, but gave the green light for me to survey either of her other two. So in the end I got twice for what I was bargaining for.

This month will be the next test. I have to actually report out the results to my peer group. The target value of 80% won't be met so there will be some explaining to do. In all honesty, I'm thinking that reaching 80% attainment in the first quarter of a projects lifecycle is very ambitious. So a note to those interested in implementing this kind of measure, aim for 80% by end of year. The target for the first quarter should be something much less ambitious; say 50%.

Sad Moments; Thick Skin

Just a quick departure from my measurement focus; to say that we project managers need to have thick skin if we are going to survive.

You hear seasoned project managers talk about their scars. These come from projects that didn't go as originally planned; usually in a non-favourable direction. So I am dedicating this post today to all those project managers out there with heavy hearts, for whatever reason you are feeling somewhat dejected, cheer up - your going to wake up tomorrow with the same insane passion that put you where you are today, doing what you love most!

Project Measurements - First Pilot

Yeah!!!.. The first pilot of the new Project Performance Index went exceedingly well today. The project group consisted of 7 team members (plus me = 8). I consider this an optimal size to get a fair cross section of opinions. The team was asked to rate the three performance categories across the range of "Great", "Good", "Caution" and "At Risk". These rating scales are used elsewhere in other project status reporting tools so they were a natural fit to use here.

Before asking the group to rate each I framed up the context within the three categories. This gave them a common understanding of what was to be considered, and hopefully educated them about what is considered important.

Initially I was surprised at the results. The team rated both Business Performance and Project Performance as Caution to Caution - At Risk. And to their credibility, these brutally honest results were shared among the group. However at second thought, I now consider these results as to be expected. The rationale behind this is that the project team has only been together for one month now, and would be feeling somewhat disjointed and unsure about the project.

The real test as to whether doing this measurement was time worth spending is if anyone saw value in it. Fortunately this did occur, and I suspect because not only did we surface some undisclosed concerns, but because we came up with actions to move the rating towards great.

The exercise also gave me further insight towards representative samples. In order to assess project performance across the corporation I need to survey projects at different times within their lifecycle.

PPI - Stakeholder Survey Template

Ok.. here is a model of a template I'm contemplating as part of the Project Performance Index toolbox. This template is a survey for assessing stakeholder engagement. It is one method for testing the business performance component. The survey has 8 categories:

- Risks
- External Dependencies
- Sustainment
- Resource Management
- Strategic Alignment
- Documented Procedures
- People, Process, & Systems Alignment
- Short Interval Control

Each category has one question, posed in the form of a statement. For example, the question for assessing stakeholder engagement for Risks reads:

"I am comfortable that management manages the main risks and issues on the project."

and the 5 possible responses are:
Always, Frequently, Infrequently, Never, and Not Applicable

This design is repeated for each question in the 8 categories.

Here is another example, the question for People, Process, & Systems Alignment reads:

"Training is aligned to address gaps with technical, customer, and process requirements."

Now I don't propose that these questions are very deep or complicated. And that is by design. The intent is to encourage your participants to complete the survey. If you make it too complicated then it will require more effort from them. The end result will be that you trade off quantity versus quality. In my opinion, your going to interpret the results anyways, so why not put the effort back on your shoulders. Remember in an earlier post I suggest that you try things on yourself before engaging others.. well allocating the effort onto you is a spin off from that advice.

Please feel free to forward suggestions on other simple questions to use.

Being cognitive of the...

....

Ok so your probably wondering two things.

1. What relationship does the pygmalion effect have with the Project Performance Index
2. What is the pygmalion effect.

Well according to the book titled "The Knowing-Doing Gap"; by Jeffrey Pfeffef and Robert I. Sutton, it is the power of the self-fulfilling prophecy on performance.

I belive that the pygmalion effect is one of many factors to consider when developing a good measurement set. Another is the Hawthorne effect (you influence what you measure). The pygmalion effect tells us that project performance will be influenced merely because we believe that it will, and visa versa.

So if this is the case, then why go to all the bother to develop and track a measurement system? Hmmm.. the answer is because nobody will want to trust and/or act on faith alone. However that shouldn't preclude you from using this effect to your advantage.

So my advice is to tell everyone how great adding a measurement system to projects will be, and how much better projects will perform once they start getting measured... trust me..

Project Performance Index - Part 1 of Many

I am committing to make this blog posting one of many pertaining to establishing a project measurement system called "Project Performance Index". The interesting aspect of this is that posts will be listed top to bottom, latest to earliest. So I apologize in advance to the reader who may be totally confused about the content they are reading.

In general, the project performance index would be a validation of Business performance, Project Performance, and Team Performance. Tangible criteria that can be evaluated early and often is recommended however this does not preclude using less tangible criteria such as customer satisfaction or instituting change.

Business Performance: Meeting or exceeding the projects value proposition and the sustainment effort required to position the end product for success into its life cycle.

Project Performance: Meeting or exceeding time, cost, and technical performance objectives (ie: delivery of a product or milestone on or before the time it's required, at or below cost, and within the range of design or performance specifications).

Team Performance: Meeting or exceeding the behaviours that ensure the team functions as a unit and not single entities. Collaboration, sharing of idea's, respecting one another, and contributing to a common goal.

I want to close off this entry at this point but before I do I'll leave you with two thoughts;

1. Despite best practices; organizational culture will influence what measures are accepted.
2. I quote a section out of the book titled:
   
   The Complete Project Management Office Handbook
   by Gerard M. Hill (ed)
   Auerbach Publications © 2004
   
   From Chapter 3: Standards and Metrics
   The "standards and metrics" function enables the PMO to:

• Identify accepted concepts and practices for use within the project management environment
• Establish consistent oversight and control for cost, schedule, and resource utilization
• Manage project, technical, and business process performance to desired standards
• Achieve compliance with industry standards, regulatory mandates, and business policies
• Conduct benchmarking related to competency, capability, and maturity goals

These are great points. The next step is to explain what they mean using a language that the people who sponsor and lead projects understand.

Quick and Easy - A tip 4 You

This is a special post - call it a quick tip:

1. Since Communication makes up about 80% of your project; then communicate early and often
2. Don't wait till your project is fully planned before starting; it will only change again tomorrow
3. If your going to insist on doing something, then start off doing it yourself first.
   

Project Measurements

So let's say your interested in measuring the performance of your project. How do you go about this? Do you go for a plain vanilla measurement set; measuring quality, time, cost, and scope? Or do you get a bit more creative and measure team effectiveness, management effectiveness, and project process compliance (risk management, change control, phase closures, lessons learned.. etc).

The altruistic reason to measure performance is so you can do something about it before it is too late. Therefore adopting measures that indicate outcomes of a process will likely be ineffective. These are sometimes referred to as lagging measures. If you want to do something about a process before it is too late, then your going to be in a better position to do so by adopting leading measures. Leading measures look at the process while it is still active. As project managers you recall the control chart (run charts). This is an example of a measurement system designed to provide in process measurements.

So if your considering adopting a project measurement system, consider then that projects get behind one day at a time; and your measurement system needs to be dynamic so that it can give you the timely information required to steer the project back on track.

What is Project Management - really..

I'm getting softer in my ways. Either that, or I am getting a better idea as to the true nature of effective project management. You see, I've been moving away from tool solutions as the goal and instead, spending more time just working the social component.

This social component, is being focussed on the interests of those people who need to take ownership. Being focussed on how they assemble and process information, on what motivates them. Understanding... and then tooling... And if there isn't an appetite for the tool or method, then there is always tomorrow.

The danger with not enforcing rigid adoption of project management methodology is that.. Gosh!.. it is supposed to be the most effective methodology designed to manage projects.. So all the while, when the project leader is busy working by intuition, the project is likely falling behind. This becomes all the more dangerous when there is an expectation that your supposed to be the person charged with the responsibility for establishing the methodology.

Ok.. so does this mean that it is best to avoid letting the project leader's motivating factors lead the adoption of project management methodology, and instead, enforce a rigorous adoption. Heck - why not! My answer is still no.

I don't think I'm soft. But here is the catch. Sure, let the project leader lead. Your role is to interject from time to time with sound project management advice. Look for opportunities to roll up your sleeve and build the missing project methodology into the project. Offer to record the meeting minutes (some places use action logs in place of minutes), speak to them about potential risks - just don't become evangelistic about them.


So what is Project Management - really.. Let's say it is whatever it takes to get the project moving in the right direction, using consistent management processes, and without crushing leader (and the team) motivation while your at it.

Team Performance

Gosh.. here we are in 2007. And my oh my, where has the time gone. Considering that this wonderful blog has only a pittance of updates then I guess there wasn't all that much to rant about in 2006.

I've been actively reading up on team development, methods to keep individuals engaged as a high performing team. The content came from a corporate leadership book that was published back in 1995. My immediate reaction was that this outdated information is not worth the read.. but it was.

There were a number of very interesting strategies mentioned. Each required a dedicated commitment; not quick bandaid solutions.

• Establish currency: The idea here is that you create a monetary reward system that team members receive, and can use to pay others that they depend on to get work done. The currency value is in the form of shares. Share value is determined at a regular basis and is based on meeting the quality, and performance objectives of project milestones.

• Peer review: Team member performance is evaluated by the team. Each member is judged by their peers towards demonstrating the requisite competencies for success. This helps to avoid where team members feel that they are carrying the load for non-performing team members... using team based competencies helps avoid individual local optimization at the expense of others.

Yes, there were many other very interesting options.. but not enough time to write about them today.

Project Closure - what works?

Closure - In my books, probably one of the often mis-practiced components of project methodology. Funny how this is considering that "lesson's learned" can be found in the PMBOK so many times. I don't recall the statistic exactly, somewhere around 200 times. Why do we not practice closure in a timely fashion? I suspect that one reason is because people associate closure activities to signify that the project is completed, and not just that the current phase is coming to an end.

I've yet to find a closure process that keeps people interested. Perhaps something is wrong with the approach? I tend to favor the following:

1. Evaluate what is in scope and do some preliminary analysis
2. Develop a plan that includes tools, techniques, responsible people, and end state
3. Communicate the plan to the responsible people to obtain their buy-in
4. Assume responsibility for the grunt work that is not unique to any one person
5. Review progress to completion

In most cases, this approach and a dollar will buy you a coffee. I think that the strategy goes sour somewhere around step 3. Unfortunately, this is not known until step 5, and step 4 got the go ahead because it was really just an extension of step 2. I believe it is better to do your homework ahead of engaging the team with the plan. However if this the reason why the end result is often less than satisfactory then here are some factors to consider.

1. One could blame the methodology developed in step 2. At times I've elected to employ technological solutions to help out. Perhaps this introduces more risk towards acceptance. I've found that technology is somewhat indispensable in the case with document closure activities. One time I recall having to create a custom database application to help disseminate 50,000+ documents to their rightful home.
2. Perhaps even earlier than step 2, to include the team in the scope evaluation process done at step 1. They may not agree with the prioritizing or level of importance. I've noticed this with closure reports. Despite having a standard report, the fact that this becomes a formal document probably gets people a bit nervous and unwilling to commit.

I could go on and on I guess. Despite my ramblings here we are again in the year end closure phase. I wonder if history will repeat itself.

Maintaining a positive composure during conflict

The saying goes that conflict is not necessarily a bad thing. It is merely an expression of different positions or interests. So why is it then that people perceive conflict in the negative? Why is it that when a conflict situation arises we feel bad about it? Where do we draw the line between being hardened against the feelings of those around us versus not providing criticism for fear that it will not be perceived as being helpful?

To complicate this scenario I refer to the team building model; forming, storming, norming, and performing. I subscribe to the notion that a team will experience each phase, and fall back a notch or two when a new team member is introduced or removed.

Some methods I’ve seen used:

1. Ground rules: This is the preferred approach. It is often used for a long-term engagements yet usually don’t get appreciated as being of much worth. Ground rules can describe a host of circumstances such as being on time for meetings, sending a designate on your behalf if you cannot attend, allowing one person to speak at a time, etc.
   
2. Coloured Cards: If a person is offending another then they can raise a red flag. There are other flag colours for expressing agreement or caution. I’ve seen coloured cards used as a subset of ground rules.

Yes there are many other tools, just refer to the PMBOK Guide 2003 edition under “Develop Project Team”.

Regardless of these tools, I often observe that it is challenging to engage the collective members in a friendly and collaborative context, not one that is perceived as being hostile. And I find the transition from friendly to hostile occurs very rapidly.

So how does one maintain positive composure? I leave off with the question - How do we ensure that all parties are working towards a common goal, and as such, able to accept conflict and criticisms that arise in pursuit of it? I suspect there is no simple answer. As always, your comments are welcomed and appreciated.

Building the Agile World - one vendor at a time

So today we discussed the Agile approach to implementing software. I thought this would be the easiest part of the entire 2 day workshop. Egad... nothing of the sort. The vendor didn't demonstrate a passion towards this approach. I use the word passion because I don't want anyone to think that they weren't willing to consider the methodology.

The customers interest was to have fixed incremental delivery of value, that the business user could touch. Doing so would lead their end users down the path towards acceptance in a timely manner.

The vendor seemed to feel that it would be difficult to stay fixed to a 30 day incremental release as it would be difficult to package subsets of their system modules. They did admit that the business users like to test the modules in lieu of their business processes, and as such, do require only a fragment of the entire module as a result.

The end result - you tell me... have you encountered a similiar experience?

Being Systematic to achieve results

Pondering about how well projects are managed by non-project managers (those without any formal training in project management) makes me think that it is time to get back to basics. Time to revert to being systematic about applying project management practices in order to achieve results.

I'm referring to the purposeful execution of project methodologies such as

• risk identification and review meetings
• stakeholder communication meetings
• schedule planning and review meetings

as deemed applicable according to the right methodologies determined to be beneficial to the project. My suspicions are that the non-project manager is more susceptible to loosing out on the benefits derived by applying these methodologies if their execution are left to chance.

I am speaking from a gut feeling when I say this. Always wondering how to best advise the non-project manager on the right application of the methodologies without them feeling like it is an unnecessary burden or bureaucratic nightmare. What concerns me, and leads my thinking towards insisting on a more rigorous approach, are three things:

1. Lack of formal risk management activities
2. Fits and spurts of planned activities
3. Under utilized team members

The problem is how to influence those in charge of projects to adopt a more rigorous approach.

Negotiation

Have you read any books about negotiation? I have. I also sat in on a seminar led by the infamous Herb Cohen, noted negotiator and author of many books on the subject. The methods I've learned from these encounters are essentially the same:

1. Get ready - do your research on the subject prior to negotiations, acquire references to external sources for comparison and as a means to decide when a deal is a no go
2. When you meet, refrain from getting to the bottom line fist, seek to understand each parties interests first
3. Once interests are articulated, start brainstorming various options available to satisfy those interests
4. Boil the options down to the critical few and then determine which standards are applicable to them (this is where your research helps)

Those of us who have any insight into negotiation can appreciate that these steps are extremely high level. I welcome your comments; successes and or failures that you have in applying these.

My successes have been limited. For instance, I recently purchased used car. I found myself in a high pressure situation with little time to apply the principals;

• the car was a 2002 model with very very low mileage
• the price was just under my limit (taxes and other admin charges put me over)
• there were other interested buyers - or at least test drivers
• I was without a personal mode of transport in the next two days, relying on the car pool
• I encountered unknowns such as extended warranty, and corrosion package costs

From a lessons learned perspective, my method for preparing and adherence to a disciplined approach could have been better. I chose to do a simple price comparison using online car classified ads such as the ones found in autotrader The lesson to learn from this is to limit my field research to the same vehicles. The second thing I should have researched was the cost of rust prevention services and extended warranty offerings. Neither had I elected to consider and therefore had to rely on memory during the crunch. Lastly, if financing is a concern, then compare rates.. The car dealer was ready to offer me financing. I could have done my homework in this area ahead of time since I already knew my preferred lender.

How to get "buy-in" to solutions

The next generation of me.

How to get people to accept a solution:

1. Identify the problem at hand as you understand it, but refrain from proposing a solution.
2. Being a natural tendency for people to maintain their status quo, they will assess the threat that the problem presents.
3. If they perceive the threat as a bad thing, then they will attempt to avoid it.
4. If they perceive the threat as a good thing, then they will embrace it.
5. Allowing people to make their own decision will lead to a greater level of success and less frustration on you.

So the moral of this story is to always position your threats as good things.

If that doesn't work, then loosen them up with alcohol first. :)

Hey Hey - here's what I have to say about Planning & Scheduling

Woo Hoo !!! Entry numero uno.. Soo.. thanks for dropping by.
Ok - I believe in the value of planning. If I had to rate my preference on a scale of 0 - 10, where 0 = fully intuitive and 10 = fully planful, I would come in around 7.5 This is somewhat driven by what motivates me instead of what I know I should be doing. As such I may not always practice what I preach.

Planning & Scheduling software I use regularly:
MS Project - Yeah.. great tool.. wish I was a better master of it.. Maybe I should join MPUG and stop crying about what a hack I am (or maybe my attitude about this is like golf, the better you get the more you beat yourself up about not being better). I think I'm a hack because I don't take full advantage of linking tasks or creating the right kind of task. I think you can't take advantage of links where meetings are fixed. Then there is the choice between a task based on fixed duration, fixed work, or fixed whatchamacall it. Which then takes into consideration the resources, their schedules, etc.. yeah.. it is all good, just that it is complex and therefore cannot be picked up by the first time user easily.. and what about those reports and views - excellent yet again.. if only, if only.. which leads me into the next tool - the excel conglomeration-

Excel Conglomeration - this is a homegrown tool that I've been developing over the last few years. It is simple yet with the help of some macro code, gives the user a way to view tasks due each month, reschedule tasks, and track attainment. With the right behaviour, it can be pretty effective. This tool is the tool of choice with the groups I work with. The reason being that it is based on excel, a platform that they are comfortable with. There is no linking of tasks. The planner is asked to break down the project deliverables into discrete tasks that will take no longer than 1 month to complete. The approach is to review the tasks due in the upcoming month, therefore providing the person has enough leadtime to think about the issues, and communicate their requirements, and confirm commitment to the involved parties.

Well .. enough said for now.. please feel free to comment about what you have read. I'm keeping this short for the time being until I learn more about blogging. Hopefully I can start attaching audio podcast to these entries.