Free Communications Management Plan Template

I participated in a Communication Working Group session for the PMO today. Imagine a dozen people sitting around a table laughing for 10 minutes, when they realized I had shaved off my goatee. After the excitement subsided, we rolled up our sleeves and got to work. It was really quite refreshing to see how excited everyone was to be there. (We only had 4 people for the prior meeting) Ishikawa diagrams littered the walls and the smell of Scripto markers filled the air. I can't stress enough how important it is to have a Communications Management Plan.  Feel free to download my template.  If not, I recommend following the next 7 steps to write your own.

1. List the project stakeholders and their associated roles and responsibilities
2. Specify contact information for each stakeholder
3. For each stakeholder identified, specify the information required to keep stakeholders informed and enable them to fulfill their project roles and responsibilities. Also, specify the timeframe, frequency, or trigger for distribution of the information.
4. List the information that must be collected, summarized, and reported in order to produce the communication outputs that fulfill the stakeholder information requirements. Specify the associated collection and reporting details.
5. List each report or document to be produced and distributed as a communication output to fulfill the stakeholder information requirements. Specify the associated distribution, storage, and disposition details.
6. List and describe the distribution groups that will be used to distribute project information.
7. Last, define all terms and acronyms required to interpret the Communication Management Plan properly.

Contribute for the better good

I just posted an update to the Agile Scrum definition on Wikipedia. It has been a while since I've made updates to this definition and others on the free online encyclopedia.  It's actually quite cathartic to contribute to something like Wikipedia, for no other reason then to help others.  I've been asked a lot of questions recently about Agile Scrum and its applicability to my current project.  Though I'm happy that people value my opinion, I figured it was time I revisited Wikipedia and make sure the items I've edited in the past still pass muster.  Sure enough, without telling anyone that I am one of the contributors, I've received two  emails linking to the Wikipedia definitions with notes like "You should check this out".   I hope by continuing to make contributions and updates to publicly available PM related topics, people will be exposed to my work if they know it or not. Have a great day and feel free to leave a comment!

Regards, Derek

(Image by drewpreston on flickr)

Understanding Agile Scrum and common terms

I've been in a few meetings this last week where people were mentioning Scrum terms but didn't know what they were. It's not their fault. The person introducing the terms into the project vocabulary should have provided an explanation before referencing them.

For those of you new to Agile Scrum, here are a few basics:

What is Agile Scrum? There are many specific agile development methods. Most promote development iterations, teamwork, collaboration, and process adaptability throughout the lifecycle of the project.  Agile methods choose to do things in small increments with minimal planning, rather than long-term detailed planning.  There is a heavy emphasis on face-to-face communication over written communication.

Agile Scrum is not ideal for every project.  If the project has high criticality, is using junior developers, has clearly established requirements that do not change often, employs a large number of developers, you should think twice about using it as your method of choice.

I've seen it work very well with small (5-9 member) teams, where all the stakeholder knew they wanted "something" within a short period of time.  They did not know specifically what it was nor how to get from start to finish.  We used a lot of wireframes and prototypes to get us in the ballpark, until we could lock down clear functional and design requirements.

I think it's important for people to understand key terms in Agile Scrum as they relate to other project management methodologies.

Roles

Product Owner The person responsible for maintaining the Product Backlog by representing the interests of the stakeholders.  This owner could be a project manager, director...  Whatever their title, they must have the authority to make decisions on behalf of the project.

ScrumMaster The person responsible for the Scrum process, making sure it is used correctly and maximizes its benefits.  This is NOT a project manager.  This person is a facilitator.  They are merely there as a communications bridge and to offer motivation or remove impediments.

Team A cross-functional group of people responsible for managing itself to develop the product.  This is a small team (5-9) consisting of at least one person from each area (BA, QA, Risk, CM, Software Engineering...)  This team traditionally sits in the same room or area.

Scrum Team Product Owner, ScrumMaster and Team.  Everyone directly involved in the project, with the exception of users, stakeholders, and managers.

Artifacts

Sprint burn down chart Daily progress for a Sprint over the sprint's duration.  This chart can replace a Gantt chart in illustration of progress.

Product backlog A prioritized list of high level deliverables assigned to teams.  This list is similar to milestone deliveries you'd find in a Work Breakdown Structure.  These deliverables will still need to be decomposed (in the sprint backlog).

Sprint backlog A list of tasks to be completed during the sprint and assigned to individuals.  These are the actual decomposed items from the product backlog.  This list must be agreed to by the entire team prior to the sprint actually beginning.  If there is a change in the scope of the sprint backlog during a sprint, the sprint must be immediately stopped and scope redefined.

Other

Sprint A time period (typically between 2 weeks and 1 month) in which development occurs on a set of backlog items that the Team has committed to.  Sprint time periods are established to provide enough time to deliver something, get feedback, and begin another iteration.

Product An output requested by the customer.  It is a completed document, process, web page, database...  Regardless of what it is, the customer believes that it has value.

Other terms to be listed in a later post: Sashimi, timebox, daily scrum, chickens, pigs, retrospective, user stories...

Using Agile does not mean a lack of defined process

Agile Scrum process

Sometimes I'm not surprised to hear one of our current contractor say they are now usingAgile.  This is their explanation for ad-hoc builds, lack of documentation, and lack of predictable process.  It can be frustrating to hear of development groups using it as a scapegoat.  Waterfall has been the decided process for our main program I'm working and it makes sense.  The requirements have been clearly identified, for several years.  The budget and schedule have been fixed, for several years. I'm not saying we can't use Agile in different areas of the program.  But, most important the current contract is not structured to support it. The contractor does not seem to understand the difference between cowboy coding and Agile.  Agile teams, do follow defined and often very disciplined and rigorous processes.  What is lacking, by this contractor, is any example of a defined process.

Agile certainly can work well if utilized by people who know what it is.  I've signed the Agile Manifesto. I know what Agile is.  Don't use a lowecase "agile" and think you're getting away with it.

Scope Management

Scope Management means:

1. Not letting others randomly expand the scope of the project without a structured change control system

2. Constantly verifying the completion of all authorized work

3. Ensure all changes are within the project charter

4. Defining and controlling what is and is not included in the project

5. Not allowing extra work or gold plating

You can read more about it on Wikipedia.  (Yes, I contribute to this definition)

Functional Management

Functional management is the most common type of organizational management. The organization is grouped by areas of specialty within different functional areas (e.g., finance, marketing, and engineering). Some refer to a functional area as a "silo." Communications generally occurs within a single department. If information or project work is needed from another department, a request is transmitted up to the department head, who communicates the request to the other department head. Otherwise, communication stays within the department. Team members complete project work in addition to normal department work. By the way, when you go to Wikipedia and read about Functional Management, know that I was the creator of the page.

Irony

The other day my superior asked me to take on responsibility within the department in a way that conflicted with my original role.  Back in October 2007, I was hired as a functional manager.  A few months ago, the department hired its first project manager.  Our department never defined itself as projectized, functional, or matrixed.  Because there were no PM's, I knew my role was clearly functional and so was the organization.  The management team knew I had a lot of experience in project management and recently asked that I start managing deliverable as a project manager while still acting in the role of a functional manager.  I explained that there would be conflict, if I indeed agreed to do that.  I was then told the department was now "matrixed".  I politely clarified by adding that upon hiring "a" project manager, we were a weak matrix.  All of the power still rests with the functional manager(s) and the project manager is merely acting as a facilitator.  I added if they wanted the project manager(s) to hold a majority of the power, that is known as a strong matrix.  There was silence.  The response was, "then we want our organization to be a strong matrix". A few days later, we had a team meeting.  My superior brought me and my team into the conference room and handed everyone a printout from the Wikipedia website for Matrix Management.  I was silent as he attempted to explain to the team that they should now be getting direction from the project manager(s) and that I would be working in a more supporting capacity.  They all looked a bit confused so I walked over to the white-board and offered an illustration of what model we were and what model he was proposing.

What I didn't tell them (or my superior) was that I am one of the contributing authors of the Matrix Management definition page on Wikipedia.