If you have been following the series (link 1, link 2) of articles on using IBM Connections as a Project Management tool, you’ll be aware that we are working through the Association of Project Management’s key components of Project Management. This time we’re up to:
Developing and Implementing a Management Plan for the Project
The Project Management Plan (PMP) is a formal, approved document used to manage project execution. The PMP documents the actions necessary to define, prepare, integrate and coordinate the various planning activities. The PMP defines how the project is executed, monitored and controlled, and closed. It is progressively elaborated by updates throughout the course of the project.
The PMP is essentially the blueprint which you will use to run the project. It’s not the project schedule but the rationale, guidelines, procedures and organisation surrounding the project.
Often people immediately reach for a word processor document or even a presentation to record these details. It’s my belief that these tools are not best suited to this job, as you are essentially creating a handbook which lives throughout the life of the project and hence needs to be updated.
The endless duplication and re-issuing of such legacy file formats are one of the causes of the lost time and inefficiencies you can introduce into your project – sending huge file attachments round to everyone so that they have the latest version, and of course people not knowing if they have the latest version or not.
My recommendation, therefore, is to use a wiki for this. To quote from wikipedia, which in itself is a wiki:
A wiki (i// wik-ee) is a website that provides collaborative modification of its content and structure directly from the web browser. In a typical wiki, text is written using a simplified markup language (known as “wiki markup“) and often edited with the help of a rich-text editor.
A wiki enables communities of editors and contributors to write documents collaboratively. All that people require to contribute is a computer, Internet access, a web browser and a basic understanding of a simple markup language (e.g., HTML). A single page in a wiki website is referred to as a “wiki page”, while the entire collection of pages, which are usually well-interconnected by hyperlinks, is “the wiki”. A wiki is essentially a database for creating, browsing, and searching through information. A wiki allows non-linear, evolving, complex and networked text, while also allowing for editor argument, debate and interaction regarding the content and formatting.
Why not a document?
In the last article we asked the question about why we were creating a document and not using a wiki. This time, we’re turning it around. Last time:
A question which often comes up when preparing documents is when to use a wiki, and when to use something like Connections Docs to prepare a document. There are no hard and fast rules about this but if you have any of the following requirements:
- Work on the same document at the same time with someone else
- Prepare PDF or DOCX versions of the document easilyThen I would recommend using a Connections Doc file. If these don’t apply, then a wiki page is perfectly good and provides a similar level of control and manageability as the Connections Doc document.
Our Project Management Plan is a living document which will probably be updated asynchronously once done – i.e there will be revisions from time to time to specific areas, but intensive real-time collaboration on the same area of the document is not normally needed. Secondly, because this is a living document, used by people in the project, there is a reduced need to print copies off or give copies to people who are outside of the project. Therefore, in my opinion, the convenience of a wiki outsells the need to handle it as a document.
Project Management Plan Structure
A project management plan often has the following basic structure:
- Project Scope, including:
- Business Purpose
- Problem / Opportunity Statement
- Project Constraints, including:
- Key Assumptions
- Project Approach
- Whether to build or buy something
- How the output of the project will be delivered, e.g. in phases, releases, tracks, iterations
- Whether significant parts of the project will be delivered as sub projects.
- Project Organisation
- Highlights key members of the team
- Shows the hierarchy of groups and individuals
- Defines the roles of the different groups and key roles
- Defines the project stakeholders
- Risk Review
- Define the risks involved, what impact they could have and how they will be mitigated
- Define open issues and how they will be addressed.
- Define dependencies would if they were to fail would affect the success of the project
- Preliminary Schedule of Deliverables
- Preliminary Project Financial Statement
- Project Communication Strategy
- Where will information be stored
- Team calendar / availability
- Tracking tasks
- Distribution lists
- Meeting schedules
- Change Management
- How will changes be handled in the project
- Risk and Issue Management
- How will risks and issues be handled
- Financial Management
- Baseline the financial situation
- Status reporting the financial situation
- Upcoming key milestones
As you can see this is quite a long list of information that you may need to pull together if you are formally managing a project. A change to the text in any of these sections would require the re-publishing of the entire PMP to everyone concerned. This is hugely wasteful, risky and time consuming.
So lets look at how we would construct our PMP in a wiki:
First lets create a home page for our wiki. I’m going to call it the Project Handbook:
I typed some basic text and created a heading. Now I want to connect the bullet points to their pages so that it acts like a kind of home page for the wiki:
I select the text, and click on the + to select Wiki Page Link
A dialog box comes up listing the pages, so I select the Project Requirements page.
Once I am done, I save & close the page.
So that this Project Handbook page comes up when I click on Wiki on the menu bar, I move the Project Handbook page up to the top of the list of Wiki pages by dragging it upwards.
I open the Project Management Plan page and put in the structure I outlined above:
I go through the bullet points and select each one, pressing the + button and selecting Quick Link to make the text into a page link:
Once I’ve completed this, I save and close the wiki page. When I click on each of the links on this page, the wiki flags that I don’t have this page:
I click on Create This Page to make the page and establish the link:
I can continue doing this for each link, essentially making a new page for each part of the Project Management Plan as I need. I can create sub-pages in the same way and link between pages using the Wiki Page link technique like you saw before.
Remember that the wiki maintains all versions of each page so it’s easy to revise and replace text.
The other benefit of using the wiki is that participants can choose whether to be informed of changes to a specific page, or the whole wiki. Rather than you broadcasting each change that’s made (sometimes to people who may not be interested), they can choose to pull the information about changes to parts of the document that affect them or they are interested in.
Users do this by going to the Following Actions link and choosing to follow that Page, Wiki or to stop following as appropriate.
Join me next time when we will tackle leading and motivating the project delivery team.