Making the working group work

You are NOT a PM who has kept up with the times if

• You are not facilitating a working group (WG) with adequate technology, business and QA presence
• The WG is basically a status update call
• Even worse, you don’t have a WG setup!

Some things you can do to setup and facilitate an effective working group are are

Get the "purpose" right

• To provide people the forum to raise obstacles in their path
• Resolve issues needing collaboration with different teams (or take actions to solve offline)
• Share planning information - set expectations on plan
• Make recommendations to the steering committee

Get the right "participation"

• Get Representation from Technology, Business Analysts, Business (Line) and Quality assurance.
• DO NOT let participants forward your invite unless done for delegation.
• Follow-up for lack of participation

Get the "agenda" right

• Move the agenda with project evolution i.e. At the start of the project, use it as a planning forum - use it to get assign actions on defining governance, project communication, project objectives, defining scope, close resourcing etc
• Close on the high level approach to deliver the system (take this to steering for approval)
• When you start to get an handle on the project releases, discuss the high level plan and get buy-in from people
• Move to a SDLC based agenda once the release plan is being tracked. Get in agenda Items to track Requirements, Design, Build, Testing deliverables.
• Have a slot for people to bring-upp issues regarding to the project
• Dedicate atleast 30% of the time to track on actions from previous projects (best done at the start of the meeting)
• During important milestones, use the WG as a checkpoint. Use it to disseminate the information to the stakeholders.
• Before each meeting, ask yourself - What is the biggest issue plaguing the project - Table it for discussion and resolution as a separate agenda item.
• AOB (Any other business)

Get your "position" right

• Ask the right questions, Let people talk
• Representatives should provide an update on behalf of their teams and highlight dependencies on other teams. Your question should be - Is there a dependency you have on getting this done by 16-Jan? or do you think there is a chance we might miss this deadline for the 12th-April-2011, why do you think so?
• Cthe right action and confirm with the action owner during the course of the meeting.
• Be the scrum master, not the task helper.
• Stop the fighting between different teams and present the issue in a progressive sense example – When BA’s and IT disagree, narrow down to the point of disagreement so a resolution can be found. Discourage team positioning against each other
• Get the quiet ones to talk. Example “Hey Bart, we haven’t heard from you on this one…are you happy with it?”

Hope this helps!

Things we easily forget

Peeps, this is a bit of a random post, but one that discusses the items that are easy to ignore. PMing is not a job, its an ownership. Been making post-its for myself of things to engrain in my approach. The mess on my desk has become unbearable, so I am transferring it to this electronic medium!
Friendly & Firm can go together - No one likes a tight arse, dont be one. Break the formality while dealing with business users & put them at ease. Being formal (officious is worse) makes you come across as COLD in your relationships. Relationships salvage projects from tough situations, and without close bonds, you will be handicapped.
Protect the primary objective of the project - Most projects that are undertaken in an end user organization will usually get more than 1 streams of work. In such a situation, identify tehprimary objective and ensure that all decisions regarding scope, budget & delivery protect the primary goal of the project. IMPORTANT!
Retain the ability to Say "No" - Not all the items on the project wishlist can be taken. This trait separates the average PM's fromt he good ones. Say No firmly, but with firmer reasons to backup your argument.
"Plan" content and acceptance, not tool and beauty - This is a bug that infests a lot of PM. There is a lot of focus in getting the plan "finished" and making it "beautiful" rather than focussing on the content and buy-in. Follow 70/30 Spend 70% of the time getting buy-in & content and 30% to make it presentable.
Back your decisions and be seen as a prick vs Succumbing to what stakeholders say - Interesting one this is. But here is what i say. If you believe in something for the right reason, back it up to the hilt. People may not like it, but will recognize teh value later. Everyone likes a well deliverd project. Liking the PM is just an added advantage. Plus if "everyone" likes you, start getting concerned :)
Inheriting a team does not mean you need to retain it - Applicable when you walk in to an existing team. Take time, understand their capabilities , but do NOT be afraid to rejig them around if you believe that it will help the project.

Start the race right!

Often times I've been faced with a situation that needed the project to be up and running ASAP. As project managers, you must have faced this situation all the time. Sometimes, its the sales pitch causing more pressure on delivery, sometimes it is a valid customer driver needing the product out faster. Regardless of the cause, the impact on the project is predictable - you may well get off the blocks faster, but like all marathon runners know- it may actually set you back in the race at the end. Remember that Finishing the race is always more important than starting it. The trick therefore is STARTING THE RACE RIGHT!

In no way is this list exhaustive, and I am the first to admit that I have only learnt from the numerous mistakes I have made! Looking back, here is a synopsis of things I could have done better and things I managed to deliver :). I purposely use a tactical style so you can easily relate it to your projects. The first thing to acknowledge is that there needs to be a plan for setup. However, do not expect it to be sequential. It is unreal to expect that you will get dedicated time to setup a project before it really begins. Reality throws the project at you and you will need to start some form of execution. Don’t worry about this so long as you keep crossing items from your project start-up checklist.

YES I RECOMMEND A START-UP CHECKLIST instead of a sexy project plan for managing the starting phase of the project. The rest of the process pans out much easier if you see it as items to knock off the checklist, rather than a plan/schedule with dependencies.