Quick Minutes – Quick meeting minutes are better than no meeting minutes.

As a PM you usually have the task of creating minutes after meetings.  Important or client meetings usually have formal minutes published.  Team meetings or quick meeting sometimes are not.  Let’s face it, meeting minutes are not one of the most interesting tasks of our role, but they are required.  You need to capture the discussion points, decisions and action items.  The best way to do this is via what I call Quick Minutes

The point of Quick minutes is to capture the salient points and all action items in the meeting.  The minutes do not have to be verbose and packed with the details of the conversation.  Just capture the most important parts of the discussion. Action items still should contain the task, who’s responsible and a target date.  If you are using an overall project action log, you can capture the new action items there

Here’s a sample of what I call “Quick Minutes” usually emailed out by end of day of the meeting to all the participants or stakeholders. 

Quick Minutes/Notes from today’s meeting

1)      Testing is delayed, additional two weeks required.  Project can absorb the delay.  Pushes date to June 19^th.

2)      Three UAT environments being developed.  Will be complete by Monday May 18^th.

3)      New report mock-ups required – Action BA – confirm requirements by May 20^th, DEV Complete by May 27^th.

4)      User Guide Updates - New date TBD (action – BA Date for a date by end of week.)

5)      Confirm/Meeting with John to discuss UAT testing (action PM - ASAP)

6)      Penetration Testing – Needs to be performed vs a FI instance in UAT. 

7)      Identified Dependency: IMPORTANT: Identified project is impacted by project ABC.  Action – PM: Inform stakeholders ASAP.  Impact to deployment timelines.

The minutes are very loose and free-form, but contain the key items from the meeting.  The above Quick Minutes are better suited to internal team communications.  If you are sending quick minutes to a customer or vendor you may consider additional formality and content. It depends on your audience and the relationship you have with them.

I’m not suggesting that all meeting minutes be captured this way.  But, if you’re cramped for time and have important notes and actions that do need to be captured, you can use some Quick Minutes.

Matching Project Management Style with your Project or “Shoes must match the belt”.

After you’ve had a few projects under your belt, you’ll soon realize that no two projects will be exactly alike. Of course every project is different in the sense of scope, budget and time-frame.  Each project has its own set of challenges and unique aspects. To be successful, you need to modify your project management style depending on the project.

In broad terms I see two camps of PM’s; “Active Project Management” or “Process Oriented Project Management”. Obviously, there are more variations between the two styles. For this post I’ll take a look at the two different styles and see how they can be used in different projects.

Active Project Management or “I want to Rock n’ Roll all night, & PM every day!”

Some projects need an Active project manager.  What I mean by active is not ‘micro managing’ rather someone who is close to the team, front and center working through problems, providing leadership and solutions to the challenges. 

Active project management is great in quick “Got to Happen” projects.  The closer you are to the project the faster you will be able to identify the risks and challenges.  It’s also great in a small team where you’re involved with the details, providing support & pitching in where required. 

The pitfall of this style is that you are ‘too deep in the weeds’.  Being so embedded in the project may make managing upward more difficult.  It also requires the project manager to have specific industry experience of the project.  A “Context Free” project manager may find it difficult to use this management style.

Process Oriented Project Management Style or “Percent complete on task?  Anyone? Anyone?  Bueller?”

In contrast to the above, some projects need the project manager to be removed from the project details.  The Project Manager needs to have an overall view of the project and keep a holistic view of the project.  In this case the PM is used as an escalation point to help resolve issues. 

Process Oriented project management is better suited for larger, longer projects.  Projects that require significant overhead for a process heavy environment where you need to keep detailed documentation.  In these projects being away from the detail is required because there would be too much to manage at that level.  Your efforts are better used to manage the project from afar and keep it moving.

The challenges with this style is you’re too far removed from the inner workings of the project, making it difficult to pinpoint the specific challenge that you need to address.  Not knowing or understanding the details and how they relate to the broader project can impact information being reported.  This makes it more challenging making decisions that can resolve problems within the project quickly.

This post wasn't meant to be a long detailed introspection in project management styles.  I wanted to illustrate how two opposite styles can relate to different projects.  Another point to remember is, during a project you may require you to be detailed during a particular phase or circumstance.  Conversely, it may be better for you to be hands off.  Modifying your style can be the key to your project’s success.

Managing projects with a hard end date or “You want this done when?”

In many cases you are given a hard deadline to complete a project.  It could be for any reason; strategic, budget or simply a directive to get it done ASAP.  As a Project Manager, this can put you in a difficult situation.  In an effort to make the project happen you have to keep cool and stick to the basics.  It may seem that the standard toolset of Schedule, Constraint management and Risk management go out the window.  In fact these are still your best tools manage your tight timeline.

  

“Don't Panic"

Although it appears that you’ve been given an impossible directive, there’s not enough time and the risk is too great or whatever other concern, “Don’t Panic”. 

In most cases, management understands what they have requested and the overall risk is known and accepted.  Management will be there to support you, resources will be dedicated and budget concerns will be accommodated.  Resource managers will be pushed just as hard as the PM’s to make sure the project is successful.

Even in the cases where it appears you’re not getting the full support, you still have to come to grips with it and not panic.  Understand that you, your team, their managers and everyone is under the same pressure.  Use the pressure as part of pushing the team forward.

“Blitzkrieg”

In these projects, doing tasks in parallel is critical. Everything becomes compressed; requirements, development, environment builds, even testing can all be parallel at one point or another. You will have to look at each major stream and see what can be done in parallel.

If you have 25% of the requirements done then start DEV on it, have QA begin to build test cases or general planning/strategy work.  Have infrastructure begin building the environments.  The goal here is to have as much happening at the same time as possible. 

 “This, is the size of the bread box”

The one thing you do need to do is, keep control of scope.  Any change in scope; additional testing, gold plating, new requirements need to be tightly contained.  This is the one part that you have to be absolutely vigilant on as it will make it harder and harder to keep that tight timeline.

In the cases where the scope must be increased, communicate it.  Clearly define what the impact is to the timeline, effort etc.  See if the project can absorb the impact, what can be squeezed to accommodate the new work?  If you do have to push out the end date, you will have the clear reason why.

 “Iceberg, what iceberg?”

While you’re doing everything at the same time and keeping scope in check.  You still need to be vigilant with risks.  This is where a risk log will help you out.  It doesn’t have to be anything grand a spreadsheet or simple list will keep focus on any event that may impact your end date.  

Identify risks related to; delayed key deliverables, external dependencies or any other challenges that can impact your end date.  Review these risks during your daily calls and make sure the team keeps them top of mind.  Make sure your management knows what the risks are so they can support the project by removing any roadblocks.

Projects with hard end dates are always challenging and can be stressful.  They are also some of the best projects as the sense of accomplishment with finishing the project under tight timelines is rewarding.  By keeping cool, approaching the project with enthusiasm while maintaining control it will get done, on time.