Monday, December 26, 2005

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.

Monday, December 19, 2005

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.

Thursday, December 15, 2005

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?

Sunday, December 11, 2005

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.

Sunday, December 04, 2005

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.

Friday, November 25, 2005

How to get "buy-in" to solutions


The next generation of me. Posted by Picasa

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.