section-4

Collaborative Project Management – Why?

Introduction

Why do we need collaborative project management guidance? Surely all projects are running fine, and we do not need any help? If you think there might be a need for collaborative resources and guidance, hang with me for a little bit and I will go through some of the main reasons, as to why collaborative project management guidance for any group is probably a good idea.

Traditional Challenges – Failed Projects

You might think because project management is a relatively old and mature discipline, it would be practiced successfully everywhere, and there would not be many failed projects. Unfortunately, this is not the case. What we find is a landscape littered with delayed, challenged, and unfortunately, failed projects. The first two reports below are geographic – the first from Europe and the second from the US. The second two are industry reports from the IT (Information Technology) and Construction sectors.

• “EU wastes migrant aid millions with ‘chaotic and badly managed’ projects”, or so reads the March 17th, 2016 headline3 reporting on a finding by the European Court of Auditors. The report claimed that the projects were poorly designed, badly managed, chaotically supervised and, as a result, were often ineffective. Two-thirds of the 23 projects examined only “partly” met their goals. “This was often due to their excessively vague or general nature, which frequently made it impossible to measure results,” the court said.
• The United States Department of Defense canceled 18 major programs in the 2000s, having spent more than $59M, according to a Center for Strategic and International Studies report published in January 2016.4 The report explains that this money was spent “without any fielded systems to show for it.” This data was based on a sample of 18 major programs, so we assume there were more challenged projects like these. Needless to say, this is a complex topic, but the report does claim that “many of these cancellations were arguably justified due to requirements creep and cost overruns.” The report then goes on to explain the other factors, specifically “the cumulative effect of successive acquisition starts, stops, and restarts”.
• The Standish Group reported on 50,000 IT projects from around the world in their 2015 Chaos report. In one classification, the report stratifies projects into Successful (29% in 2015), Challenged (52% in 2015) or Failed (19% in 2015).
• According to KPMG’s Global Construction survey6, “Project owners said only 31 percent of their projects came within 10 percent of budget, and just 25 percent within 10 percent of original deadlines, in the past three years” and “Over half of construction project owners experienced one or more underperforming projects in the previous year.”

I could have filled more pages with other reports of failed projects, from other geographies and other sectors, but I am sure you get the point. Unfortunately, while we would think that project management is easy and natural, we know that careful and effective project management is non-trivial and needs focus.

Newer Challenges – Collaboration

Ironically as organizations strive for more and more collaboration, it has the tendency in some cases to make project management more challenging. Who would have thought that this would be the case? Let us run through six reasons as to why this can happen:

1. More initiatives in organizations around the world are now delivered, or designed to be delivered, as collaborative projects. Organizations want to complete these projects with a team collaborating well together, sometimes across different offices, countries, time zones, and companies.
2. Project teams are staffed with intelligent team members from a wide range of backgrounds and disciplines who expect to be involved in the decision making of a project. They are no longer interested in the old ‘command and control’ type of project management where they were allocated tasks, complete tasks, and did not think too much about their impact on the project.
3. I am also seeing more and more projects set up with some sort of a project site and / or shared drives, or both. The challenge with some of these projects sites, or shared directories, is that they are often populated with just some, but not all, of the project information. And, you know what they say about a little information being a dangerous thing! It would of course be safer if the project site had all the project information. That way, the extended project team could consider all the information and not just a subset of the project information before forming their opinions, making their decisions, and giving their inputs.
4. Some organizations do have people formally trained in project management, perhaps with models like the Project Management Institute’s ‘Project Management Body of Knowledge’ (PMBOK), or PRINCE2 from the UK. That said, the fourth challenge is we have what a colleague of mine termed the ‘P- MBAs’ or the ‘project managers by accident!’. Often these new project managers are business leads or technically qualified people who, by default, end up leading projects. There is absolutely nothing wrong with technical people leading projects. In fact, it is often a great idea that the person with the most knowledge is in a leadership position. However, many organizations do not spend the time or budget to send these folks on project management training. Hence, they and the project are challenged from the outset.
5. The fifth reason that projects are succumbing to challenges is to do with the so-called ‘Millennials’ or ‘Generation Y’. These are folks born in the 1980s and the 1990s. By and large, this generation, and my own children are among them, have a different set of expectations. They need to be more convinced what they are doing makes sense, is worthwhile, and is for a greater cause or purpose. They are less likely to be involved in something because they were told it was the right thing to do!
6. The sixth and final reason is that as organizations become more informal and less structured, there is a lack of guidelines and standards for the project managers to follow. Most organizations I encounter do not have a defined process or set of standards to guide new project managers. You might say this does not really matter – and in some cases, you may be right – but what if an organization wants to move people around to drive larger projects to success? Some common ways of managing projects would be useful. Similarly, what if an organization has problems delivering projects with these new project managers? Would it not be better to have a project management process to fix rather than a person to blame?

Look at these six trends above and put yourself in the shoes of new project managers. You will see it is somewhat challenging in this environment for new project managers to collaboratively manage projects and bring them home successfully.

Embrace the Change

A little earlier, I explained that it has always been difficult to manage projects. I called these the traditional challenges of the failed or challenged projects. Above I covered six newer challenges that face today’s project managers. When we look at some of these newer challenges, we also find a wonderful new opportunity. When turned around, these challenges become possibilities to manage projects in a very different way. If some very smart people are willing and ready to help manage your project to success, and if modern collaborative tools are coming on stream, why not take advantage of these new possibilities? It makes a lot of sense not to fight these challenges, but to embrace them.

Do you need Project Management Guidance?

It is possible to carry out a simple four question self-test to see if your group needs collaborative project management guidance.

1. Projects meeting expectations? “Are all your projects performing to expectations and are they delivering the results your customers expect?” If the answer to this question is yes, then you have absolutely nothing to worry about. If the answer is no, you should probably proceed to question two!
2. Visibility into projects? “Can you at least get real time visibility into these projects?” If the projects are not running the way you wish, then you should at least be able to see what is going on in the projects so you can take the appropriate actions. If you answer yes to this question, you are probably in good shape. However, if you answer no, you should probably keep going to question three!
3. Trained project teams? “If you can’t see into what’s happening on the projects, are all the people involved in the projects skilled and trained in project management or collaborative project management?” If they are all trained and skilled, then you probably have very little to worry about. However, if they are not, then you probably should proceed to question four.
4. Local guidance available? “What if the projects aren’t working the way you wish, you can’t see into the projects and the people don’t have deep training in project management, is there at least local guidance and are there templates available on how to deliver projects collaboratively?”

If you answer no to the above four questions, then it probably makes sense to develop or find some local collaborative project management guidance, and this handbook should help.

Collaborative Project Management – What?

Introduction

This chapter will explain an approach to project management that is influenced by and very aware of the enemies that conspire to make successful project management challenging and difficult. First, we need to have a shared view of what constitutes a project.

Characteristics of a Project

How do you know you have a project on your hands? Here follows six common characteristics of a project that help answer this question:

1. A project is often for a designated customer or customer base.
2. A project is temporary in nature. A project typically has a defined start and a defined end. At least it has an ideal or target end.
3. A project will have a unique and specific set of objectives that need to be delivered within the boundaries of the project.
4. A project is typically more of a once-off endeavor rather than something that is happening all the time in a repeated fashion.
5. A project is not ‘business as usual’, which is more akin to a process.
6. A project can be cross-functional, or indeed cross-organizational.

Project Management Definitions

The PMI (Project Management Institute) has established standards for Project Management. These standards are incorporated into PMBOK and define a project as:

• A job that has a beginning and an end (Time)
• At a stated level of Performance (Quality)
• At a budget (Cost) and a specific outcome (Scope).

PRINCE2 (a process that originated in the UK) defines standard approaches to project management as: “a temporary organization that is created for the purpose of delivering one or more business products according to an agreed business case.”

Project Constraints

You will also find that your project can be described by multiple constraints that are often in conflict. Here are five of the most common-place and typical constraints:

1. Scope: The scope defines the customer’s needs and the requirements expressed and implied.
2. Time: Typically, a project is required by a customer in a fixed amount of time and by a deadline.
3. Quality: The third constraint is the quality of the work required on the project. To what standard is the project expected to deliver?
4. Cost/Resources: The fourth constraint is the amount of money, budget or resources that are available to be expended on the project.
5. Value: Another constraint is the amount of value provided by the project or this iteration of the project.

It is obviously not possible to fix and agree on all five of these constraints as the projects starts, which is why they are called conflicting constraints. Let us take a simple example to explain. As you start a new project, it is unlikely that you can agree to deliver forty new requirements on your project, in one year, to a perfect quality standard, with one person on the team and deliver all the business value expected. Why not? You probably do not know enough about the specifics of the requirements. You do not yet know what else might happen in the year. It is likely that there is no common understanding of what the quality standard is to be able to make this commitment.

Given this, it is important to listen to your customer and ask enough questions, so you understand which of these constraints are really critical and therefore fixed. Is it that all the requirements must be delivered? Alternatively, is something significant needed by the end of the year, even if not all the requirements are delivered to deliver a specific value to the customer? On the other hand, is it that you need to do as much as you can with four people and a hundred thousand dollars? This is often called the time–quality– cost triangle.

Time, quality, and cost are the three sides of the triangle, representing the constraints and you need to elongate or shorten each of the sides, so they continue to form a triangle and are in balance. You may be fixing one of the constraints (e.g., time) and adjusting the other two to match. The above diagram is typical of how the challenge of constraints is represented. However, there are usually more than three constraints and therefore your triangle becomes a rectangle or a pentagon, etc.

Let me use an example close to home. In one of our groups, we now release a new product to our customers every month, so we fix the time constraint at one month. The quality and the ease of use has to meet a very high standard, as it is not acceptable to ship poor quality software. In this case, the time and the quality are both fixed and therefore the third constraint, which is the value and scope of functionality we deliver, is the one that varies. We try to fit in as much useful capability as we can in each monthly release, but we have decided that it has to be delivered in a fixed amount of time and with a very high degree of quality. In our case, time and quality are fixed and the project scope is variable. Sometimes we deliver more value than originally planned and sometimes we deliver less.

An Ideal Approach to Project Management

In an ideal world, we would be able to manage projects using the following simple process with four stages:

The process of re-planning is a constant one, since in reality and by necessity project plans do change, which is why we add the new fourth stage, “Track and Re-plan the Project.” We will explore the five stages in more detail in the rest of this Section 4.

A Collaborative Approach to Project Management

The practices of collaborative project management enable individuals from different departments, offices, companies, and even countries, to collaborate and successfully deliver a project. These practices help all team members fully engage to contribute in a positive and meaningful way to a successful project outcome. Critically, the practices also provide guidance and processes for new and ‘accidental or occasional project managers’ who lack formal project management training. In a project that is managed collaboratively, the team will plan the project together, act together and track the project together.

• Plan Together: It is best to have the team who will deliver the project involved in planning. The quality of the resulting plan will be better, and the engagement of all team members will be higher. This is probably common sense to most of us, but we know that common sense is not that common!
• Act Together: It is very desirable to have the team act in unison on the project. We all want our project teams to know what is happening and to know what they have to do to ensure project success. If the team is not acting well together, for whatever reason, as a project manager you need to take action.
• Track Together: The extended team (project manager, team members, senior executives, customers, etc.) will need to know what is and is not happening on the project in order to constructively contribute to the project outcome.

Portfolio Management

It is not uncommon for people to be confused by terminology, such as project management and portfolio management. A larger project, or perhaps the implementation of some organizational goal or strategy, will often require more than one project. When you get involved in a collection of projects, you may encounter any one of the following terms: portfolio, project portfolio, project office, or PMO. The PMO refers to the “project management office” or is sometimes called the “program management office.”

You will also see a hierarchy of project management constructs and terms that go as follows: project at the bottom, rolling to a program above, rolling up to a portfolio. There is no right and wrong use of the preceding terms or phrases. In your group, I assume that you have many, many projects and use some of this terminology. Typically, it is best to ask locally how the terms are used and in what context.

The Collaborative Tool Assumption

This handbook assumes that you wish to manage the project collaboratively with your team. It also assumes that you have access to some collaborative platform, e.g., Microsoft SharePoint or some such collaborative platform. Needless to say, the collaborative platform does not have to be SharePoint, but this is a very popular tool set. According to the Microsoft website in February 2019, “more than 200,000 organizations and 190 million people have SharePoint for intranets, team sites and content management.”

SharePoint has delivered a free version since the year 2000, so the availability of SharePoint or something ‘SharePoint-like’ is not too big an assumption these days. SharePoint 2013 Foundation was the last free version of SharePoint delivered and is an amazing product given its free price point! The newer versions, SharePoint 2016, and SharePoint 2019 do not deliver a free Foundation version.

You might ask the question – is this Section 4 of the handbook about collaboratively managing projects or perhaps more about managing projects on SharePoint? It is absolutely about the former, collaborative project management. However, we just cannot imagine managing a project without some shared project space – hence the few (but not too many) SharePoint references you will find in this section of the handbook. If you have a different collaborative platform and toolset, then please substitute the SharePoint references for your local collaborative platform.

Get a Fast Start – Track Projects

Introduction

This chapter outlines how you can easily track projects before you start fully managing them. This, in turn, ironically will help you manage the projects when the timing is right! “The secret of getting ahead is getting started.” – Mark Twain

The Essence

Why begin with merely tracking projects? Many groups are not ready for full collaborative project management and some projects are too small to get the complete treatment. What do you track? Just track the high-level project details. This is the kind of project information that is probably floating around on an Excel file. But this chapter suggests you do this with a little bit more style, ease, and substance!

Why Only Project Tracking?

Why would we resort to, or maybe start with, tracking projects rather than fully managing projects? Well, there are at least two reasons. Firstly, the project might be quite small, or is a project you find very easy to deliver as you have done it many times before. In these scenarios, it does not make sense to deploy a very large amount of project management. The second reason is you and the team may not be ready to use a large amount of collaborative project management.

This can be the case even when the project deserves and needs lots of project management. This could be due to a lack of experience, a lack of time, a lack of budget, lack of appetite; whatever the reason the team is just not ready for large amounts of project management. This can be a tough but honest call to make. In both cases, it seems wise to start with project tracking and to do that extremely well. This is an important first step towards collaborative project management. And, as we know, all successful journeys being with the first few steps.

A Project Management Spectrum

If you believe what the last few paragraphs were saying, this implies a need for differing amounts of project management. In this simple example of a practical project management spectrum, there are four sections. The sections go left to right, from Ultra- Lite to Lite to Standard and to Structured, depicting different and increasing amounts of project management. You will note that there are arrows on both ends of the spectrum. This reflects the fact that even though you start in one place, for example Lite, you might move left to Ultra-Lite at a later point or you may move right on the spectrum toward Standard. This reflects the reality that different projects require differing amounts of project management at different times.

I have found this spectrum very honest and extremely real. The next chapter, ‘Initiate the Project’, offers more details on choosing the level of project management needed.

A Natural Order

A natural companion to the project management spectrum is the aforementioned “Start|Evolve” approach. Many organizations successfully start with a reasonable and modest amount of project management, to give teams immediate visibility into what is going on, by tracking the projects. Once a project team has visibility into where the project is, it is then possible to decide what levels of control to exert going forward. This will enable the team to gradually evolve, improve and mature their project management practices with a high degree of flexibility. This gradual approach is reminiscent of the agile approach to project delivery, which advocates delivering a little and often, so that real-world feedback can be early and frequent.

Suggestion: Track the Essentials

Starting with the Ultra-Lite side of the project management spectrum, you can track the essentials of the project. These might include:

• Project name
• Project manager
• Type of project
• Customer or department that the project is for
• Required finish date from the customer
• Likely finish date based on the current progress
• Overall health of the project, as determined by the project manager
• And lastly, project status. Is this project in trouble?

Just tracking these essential key items and reporting on them, even if it is only to yourself, will help you better manage the project. If you track and report these items to the other stakeholders in the project, the team members, senior management, and the customer, you will inevitably get feedback to better manage the project. It is not that the other items like tasks, issues, risks, and change requests are not happening; it is that they are not formally tracked in a consistent, central, and transparent manner. Here we are suggesting that you begin by more formally tracking the essentials.

If you cannot beat them join them!

If I were to ask you “what are the most common project management tools in use in your organization”, you might well reply some combination of Microsoft Excel and Microsoft Outlook. It makes sense that these are in widespread use for project management because they are so easy to use.

You will often see a status report typed into an Excel file and sent around on email. While these Excel project status files have many advantages, they also have many disadvantages. Can you tell if the Excel file you are looking at is the latest version? Maybe you are not sure who updated it and when it was last updated. You are not sure if there are other Excel files are floating around. Are other people looking at a different version of the file and making decisions based on this? There is also the disadvantage that multiple people cannot safely make updates at the same time. Nevertheless, despite the disadvantages, the ease of use makes Excel arguably the most popular project management tracking tool on the planet. As they say, if you cannot beat them, why not join them!

Use Excel inside SharePoint

Many organizations will use a Projects Tracker inside of SharePoint that mimics the ease of use of Microsoft Excel. With this Projects Tracker approach, you can track the essentials of the project in a grid that looks and acts like Microsoft Excel.

This approach has many advantages. There is now a single source of project truth. A Projects Tracker is as easy to use as Microsoft Excel in its grid style and shape. It also has a version history and an audit trail, so you can go back to prior versions and see who made what changes to the project status and when. In this instance, you are not in the Excel hell that can sometimes happen with project tracking.

The other advantage is that when you save work on this Tracker, it can transform into a dashboard, which is more attractive and looks the way people would expect a project management dashboard to appear.

Traffic lights icons and high priority signs are depicted graphically. You can see multiple projects in one place and click to get more detail. You can also click to get the version history associated with this project. You are essentially getting the benefits of Excel in terms of ease of use without the associated disadvantages that are present for project tracking.

If you subscribe to this project spectrum approach for any of the aforementioned reasons, then why not use a Projects Tracker inside of SharePoint in the same manner as you use Excel? It is a great way to get many projects reported and get project management started in a consistent manner. It gives a quick win without a lot of fuss. If your organization is currently submitting project updates on Excel, it is an easy transition to make.

Summary of Track Projects

If you start on the left-hand side of the project management spectrum in an Ultra-Lite way and you are tracking the essentials of a project, you can then move more easily to the right-hand side into a Lite way and start adding in work items for your projects such as tasks or deliverables or even issues.

You get the quick start via projects tracking with the option to add in the tracking of work items on the project. This way, you get both project and work tracking. This is a very easy transition for people to make in an organization.

The key point to remember is by tracking these key items about your project and reporting on them, even if it is only to yourself, you and the rest of the team will better manage the project. It is an effective and easy start on the road to collaborative project management.

Stage 1 – Initiate the Project

Introduction

This chapter will walk you through the first of the five stages of collaborative project management: Initiation. “A journey of a thousand miles must begin with a single step.” – Lao-Tzu (604-531 BC), Chinese Philosopher

The Essence

Why would you be interested in formally initiating a project? Well, fools rush in! As a project manager, you want to know what you are getting before you officially start. At this stage, you need to secure resources for the project and ideally enlist the support of a project sponsor.

Initiate the Project in 3 Steps

This handbook breaks each of the five stages of Collaborative Project Management into three steps labelled A, B and C. The Initiate stage is about starting the project using these three steps:

Forgiveness or Permission!

Sometimes it is easier to ask for forgiveness than seek permission, and there are certainly times that this is very true. However, when initiating new projects, this is not typically the case. Ask for permission to initiate the project so that you have the resources, and more importantly, the sponsorship lined up in your favor. There are many times on the project that you will be able to crash through the barriers yourself. However, every now and again you will need the project sponsor to help you deal with tough situations or make difficult decisions. Now is the time to put that sponsorship in place.

Of course, the other reason to ask for permission to start the project is as a professional courtesy. You owe it to your management team and sponsors to let them know that you are committing resources by starting a new project in the organization.

A. Get the Project Approved, Sponsored and Resourced

The first step is to get the project approved, sponsored, and resourced. A good question to ask is what might you need for this step? Be careful in your selection of the project sponsor, if you have a choice. You want someone who can advocate, who cares about the project and who has the time to give the project. This maybe the most senior mat be. It is very likely that you will at least need a face-to-face meeting with the project sponsor. It is also possible that the sponsor will request a written project proposal, a project charter / statement. Even if the sponsor does not request one, it is a good idea to produce one for yourself and the rest of the project team.
A project charter or statement will typically contain some of the following kind of information:

• Project identification
• Project description
• Project objectives, goals, deliverables
• Resources and budget needed
• Priority of the project
• Organization/customer that the project is for
• Proposed project manager
• Type of the project
• Status of the project
• When the project should start and finish
• Any other assumptions about the project.

Certain projects will also require a high-level plan at this early stage. The amount of information and process needed for this first step will depend on the project in hand, the organization you are working for, and the preferences of the project sponsor you are trying to sign up.
The sponsor will ultimately decide if the project is going to go ahead or will bring you in front of the people that can make this determination. The sponsor should also be able to allocate the people you need to work on the project and free up any other resources such as budget. During the process, you have also started to work and collaborate with your project sponsor, which is a very important relationship for you to have. From time to time, you will need this air cover. The ideal minimum exit criteria from this step are that you have secured approval and sponsorship.
You have now taken the first step as a new project manager. Congratulations on having started the journey.

B. Decide the Project Management Process

As they say, be careful what you ask for, you just might get it! Once the project is approved, you need to decide how to manage the project and how much project management rigor you will apply. As depicted in the sample spectrum below, some projects require a lighter touch, and some require much more project management.

• Unstructured: You manage using phone calls and emails.
• Ultra-Lite: A project definition in the form of a project statement is agreed and guides the project.
• Lite: You use tasks, issues, and documents to manage the project to deliver on the agreed project statement.
• Standard: You deploy a simple lifecycle of tasks in waterfall manner, or you use a basic version of Agile with periodic sprints.
• Structured: You elect to use a stricter life cycle of tasks and deliverables with phases, gates, and change requests. Or maybe you elect to deploy the full Agile approach with all the ceremonies (i.e., backlog, sprints, sprint planning, estimation, retrospectives, etc.)

This handbook will explain a little more on Waterfall and Agile in the next chapter called, ‘Stage 2 – Plan and Setup the Project’.

Your organization may have guidelines or templates for different project types, which will make this step simpler, as you will be selecting a pre-defined approach and then perhaps tailoring it. This will make your life easier if the local guidelines are sensible!

We have found that sometimes organizations expect way too much project management. In some of these cases, the project manager is not experienced enough to utilize this larger amount of project management. In other cases, the amount of project management is simply too large for the type of project at hand.

The outcome of this step may also have been determined by the prior approval step if your hands-on project sponsor gave you a process recommendation to follow.

If you do not have local guidance, use this step to think through the typical project management items and decide which ones you need to assist you to manage your project. Candidate items include:

• Project Statement / Project Definition / Project Charter
• Goals
• Resources and budget needed
• Teams, Roles and Responsibility Definition
• Tasks
• Work Breakdown Structure (for Waterfall projects)
• Backlog, Sprints, and Iterations (for Agile projects)
• Documents / Deliverables
• Issues
• Risks
• Contacts
• Decisions
• Change Request Documents
• Actions / To Do List
• Meetings (Agenda, Minutes and Actions)
• Status Reports
• Communications
• Conversations
• Processes and Procedures
• Lessons Learned.

This is not a definitive list but a good one to get you thinking. Here you are deciding what project management you will sign up for and what you will make transparent to the project team. For example, you might decide to track issues in a list but not to manage risks formally. However, this does not mean you will not naturally carry out risk management. You will probably consider and take actions to mitigate risks in your own mind, but you are not committing to document or communicate these actions. You may also find that some of these items will have been prepared or at least started during Project Approval in the prior step.

C. Create a Collaborative Project Site

This handbook assumes a collaborative project management approach. It supposes you are acting as a project manager and not as a project dictator. It assumes you want team members and stakeholders to know what has happened and what needs to happen, so they are empowered to help you deliver and manage the project. This handbook also presumes that you want to setup a collaborative site to share this information.

There are so many free collaborative site options available today that this is no longer a big assumption. I started using Vax Notes when I worked with Digital back in 1990, moved to Lotus Notes in 1995 for my projects and then started using SharePoint in 2000. Microsoft SharePoint 2013 still has a free version, Microsoft SharePoint Foundation, so you have no excuses! Get collaborative in your project management approach with SharePoint or whatever platform you find suitable.

The site you set up needs to mirror the approach to project management that you will undertake. Below is a table depicting some templates to jumpstart your ideas. For example, on the left you are following a lite approach and managing with a few elements, e.g., Project Statement, Issues, and Tasks. On the right, you are following a structured approach and managing everything you can think of! You can start out with one approach at the outset and later evolve as project needs dictate.

Stage 2 – Plan and Setup the Project

Introduction

This chapter will guide you through the steps to plan your project, ideally collaboratively with your (new) project team. “In all things, success depends upon previous preparation, and without such preparation there is sure to be failure.” – Confucius (c550 – c478 BC) Chinese Philosopher

The Essence

As they say, failing to plan is planning to fail. At this stage, you wish to plan collaboratively the main steps of the project with the team.

Plan and Setup the Project

As you enter this stage, your project is approved and you have already decided how to manage the project, or at least you have an outline approach. Hopefully, you have also set up a collaborative site. Now it is time to earn your stripes, and plan and set up your project. You should find the following three steps helpful for this second stage of collaborative project management:

A. Plan the Project
B. Desk Check the Project Plan
C. Notify the Team of their Responsibilities.

Planning – How Collaborative?

The question at this stage is how collaborative can or should your planning be? How much should you involve your team in planning the project? You have at least three options.

The first option is to bring the team together to execute the aforementioned three steps. As a team, plan the project in a workshop. Desk check the resulting project plan, again in a workshop. Then you can easily confirm with the relevant individuals of their responsibilities because they are with you in that same planning workshop. The second option is to do all the planning work yourself before bringing the team together to notify them of their responsibilities. The third option is to do a mix of the above two. In this case you do a chunk of the initial planning for the new project and then bring in the team to help finish out the planning.

The first option, collaboratively working through the three steps, is preferable. It requires more up-front time, but has the potential to save you time in the long run. If collaborative planning is well executed, you will get a better result, i.e., a better plan. It will certainly generate more understanding and buy in from your project team. It may be obvious which approach will work best for your project. If you are finding it difficult to choose, you may find the earlier chapter ‘Make Good Decisions’ useful.

In summary, it is key to involve team members as much as possible in the project setup and planning.

Planning – Waterfall or Agile

Some projects deploy a simple task list and other more involved projects have tasks organized into a lifecycle of phases. This method of project management, often labelled Waterfall, has been successful for generations, when practiced well. The method is called Waterfall, as it evokes the image of water falling from on high to a lower point and not going backwards.

While Waterfall is a commonly accepted image for this style of project management – like many images it is a helpful but imperfect depiction of what happens in practice. In reality, successful practitioners of this Waterfall approach always go back and retrace their steps, willingly and unwillingly! They retrace unwillingly when they find a problem and must rework that which was thought to be done. They retrace willingly when they anticipate a problem, or a new need or issue arises, and they adjust the plans.

In recent years, an Agile rather than a Waterfall / lifecycle approach has been much advocated and has also been very successful. Here are a few pointers to explain the essence of Agile. To begin, I find these three principles to be instructive, as they help explain and guide Agile implementations:

• Incremental Deliveries: Deliver small amounts of the project or deliverable sooner rather than later. Do not wait for the entire project to be complete before delivering some value.
• Frequent Feedback: Setup mechanisms where you can listen to and get feedback from the stakeholders. As you might imagine, it is easier for the stakeholders to give feedback if they are looking at incremental deliveries. These interactions will be a great teacher.
• Build Trust: A true agile project requires good trust between your team and the customer. Build this trust as you proceed through the project. It is very important.

The following three practices are practical ways to deliver on the three principles above and are key ingredients of Agile:

• Sprints: Agree weekly, bi-weekly, monthly, or quarterly sprints where key deliverables are produced.
• Backlog: Have a backlog for the as-not-yet planned deliverables. This can serve to highlight the opportunity waiting.
• Reviews: Relook at the progress, the sprints, and backlogs on a periodic basis.

A. Plan the Project

The thinking in this handbook is that, at a minimum, you will need a Project Definition/Statement and also a task list (of some sort) on most projects. Additional artifacts (e.g., issues, risks, etc.) should have been nominated for inclusion in the Initiation Stage of the project (unless you skipped this stage!). Four sub-steps to plan the project are as follows:

1. Complete the Project Statement
2. Define and Allocate the Tasks
3. Add the Other Project Artifacts Needed
4. Assign the Work.

i. Complete the Project Statement

The Project Statement is also known by other names, such as the Project Profile, Project Charter, or Project Definition. This is the master project document, which communicates the intention of the project and other high-level information. In this document, you will want to make very clear what the goal of the project is. It is important for all involved to know where the finish line is. Some of this Project Statement information (e.g., status, scheduled finish date, etc.) is updated throughout the course of the project. In many cases, Project Statement information is used to collate project status reports as the project progresses. The Project Statement that you are completing here was likely started in the ‘Project Initiation’ stage, as described in the prior chapter.

ii. Define and Allocate Tasks

Sometimes you will know upfront how to organize and deliver the tasks on your project. It might be a simple task list or maybe a waterfall with phases and gates or perhaps an agile approach to delivery. If you are unsure at this juncture, it is good to have a brainstorm of the tasks needed to complete the project successfully or at least the tasks you know about at this stage. Once you have an initial list of tasks, you can then start to organize them. Here are three possible variations:

• Flat Task List: It is possible that a simple and flat task list will suffice, with no other structuring of the tasks.
• Lifecycle: Sometimes you will decide to organize your project by work packages, key deliverables, or you may follow a lifecycle (e.g., a waterfall software development lifecycle or a waterfall new product introduction lifecycle). The lifecycle decision will dictate the tasks needed and the manner in which they are organized. In this case you will typically elect to use a WBS (work breakdown structure) that has parent and sub-tasks, and dependencies between tasks (i.e., some tasks cannot start until other tasks finish).
• Agile: Perhaps you desire to run an agile project with many sprints, each lasting a fixed period (e.g., two weeks), and each striving to deliver a piece of the project. This Agile decision will in turn dictate the tasks needed and the manner in which they are organized. In this case you will need a way to manage a backlog of items, and you will also manage tasks within sprints.

No matter which approaches you elect to deploy on your project, you will need to have a place and a way to manage the resulting tasks. At this stage, you may also elect to use a simple SharePoint task list or perhaps Microsoft Project to draw up the task list and assignments if you are working with a WBS.

iii. Add Other Project Artifacts

Once you have defined your Project Statement and project tasks, you now move to generate any extra artifacts required to manage your project. If you are lucky enough to have local guidance, you can use these templates. If you are really lucky, you can create the artifacts using templates pre-loaded in your collaborative site. Candidate artifacts include goals, documents, issues, risks, etc. In essence, these are the project management sub-processes for your project. Ideally, the type of artifacts required will have been decided in the second step (Decide the Project Management Process) of the prior Initiate stage.

iv. Assign the Work

I have seen some project managers delegate all or most the work on the project and not take their fair share of the load. This is not right. Other project managers tend to do more work on the project than they need to and often find it difficult to delegate. Given that we are talking about collaborative project management, it is especially important to remember that the project work can and should be delegated.

“The way to get things done is not to mind who gets the credit for doing them.” – Benjamin Jowett (1817 – 1893) English scholar, essayist, and priest

If your project is simple with a small team, you will know who is free and not free. In this case, you will assign the tasks and artifacts to your team members as you create them in the prior two steps (“Define and Allocate Tasks” and “Assign the Work”).

Some organizations have a more formal definition of roles in use. In this case, you will likely assign a generic role (e.g., business analyst, financial analyst, customer tester, etc.) to a task or artifact in the preceding two steps. You will later assign a person in place of these generic roles. Using a project site with a list of tasks and artifacts with generic pre-assigned roles is a quick way to set up a new project. All you need to do is assign the person to the role.

In other cases, where the organization is very large and people are committed to many projects, you will not know who is free. In this scenario you will need to draft your plan to see who you need and when. Then you will need to check resource availability before you can make an assignment. In certain organizations, you will also need to formally request resources for your project.

At the end of this step, you might also want to check the resource loading, so you can find and fix any over allocations due to the new work assignments you have just made.

B. Desk Check Project Plan

“If you would hit the mark, you must aim a little above it; every arrow that flies feels the attraction of earth.” – Henry Wadsworth Longfellow (1807 – 1882), US poet and writer

By this stage, your project should be well planned. It is important to have a step where you stand back and review the plan thoroughly. Now that you have created lots of tasks and artifacts, you should look at the entire project in a Gantt (time sequenced) chart and perhaps in a Kanban chart (with buckets and cards). You will very likely see adjustments to make before the plan goes live. It is also a good idea to have some of your colleagues peer review your plan.

The Time, Quality, Cost Trade-off

As part of your desk check, you and the team should be aware of the time–quality–cost triangle or trade-off discussed earlier in the handbook. These conflicting constraints are normal on a project and to be expected. You are trying to balance the scope that you need to deliver on the project with the time available to achieve the right level of quality for the cost and resources that you are allowed to spend on the project.

At this point, you will want to make decisions on where to trade-off now or later as needs be. It is also a good idea to document these decisions and perhaps run those by your project sponsor if some of the trade-offs are significant. The key point is that thinking about the project in terms of time– quality–cost will likely lead to some revision of the planning you have done up to this point. This is positive, because it will protect your plan and make it better before you start into execution.

C. Notify Team of Responsibilities

It is all very well to plan a project in detail, but you need to let team members know the plan for success. High quality communication increases the likelihood your plan for success will come true. Project team members are very smart and capable so be sure to empower them by letting them know what is going on. This is the essence of collaborative project management. Three mechanisms to manage and facilitate this communication include:

• Involve your team on some or all of the prior planning steps.
• Host a project kick-off meeting to introduce team members to the project and walk them through the project site.
• Set up Automated Reminders: Enable your collaborative project site to automatically notify all new work assignments via email and set up the “My Work” report or dashboard on your collaborative project site.
• Use scheduled emails with nudges for upcoming or late work. For example, early Monday mornings send an email of the work due for the week and then on Thursday morning send another email with work still open and due this week.

Stage 3 – Work the Project

Introduction

This chapter will guide you through the typical project team member experience on collaborative projects and will refer to:

• Team member commitment
• Team member process / rhythm
• Team member responsibilities.

The Essence

Why do we need a stage “Work the Project”? Well, this is where the bulk of the project work takes place. This is where the actual project work occurs. You also need to be mindful that team members are extremely distractible, as you can see in the wonderful quote above from Douglas Adams.

“I love deadlines. I like the whooshing sound they make as they fly by.” – Douglas Adams (1952-2001) English Humorist

What does this stage entail? In summary, you want to give the team members some direction on how to proceed, how to work on the project, and how to collaborate. This will enable the team members to step up to the plate and help you to manage the project collaboratively.

Team Member Commitment

Your project has now started, and everybody (hopefully!) knows what he or she is meant to do. In a collaborative project, you are essentially asking the team members for three commitments as described here. You might even use these words in the three short paragraphs on this page below if you are very new to collaborative project management!

• A. Find work: Using one of the many notifications (e.g., My Work report, automated emails, etc.), find your work so you know what you are committed to delivering for the project.
• B. Do work: Naturally enough, go do the work! In many cases, the actual work products (e.g., a proposal or design) can be created and updated in the collaborative project site.
• C. Update progress on work: Use the datasheets or forms provided in the collaborative site to record your progress on what is done or in progress, and use the project site to record any issues that need attention.

Team Member Process / Rhythm

It is very likely that the team members on your projects will be involved in more than one project and will have other work responsibilities. As such, they will find it difficult to keep up with all the deadlines. In fact, do not be surprised if some of the team members are so focused on the work, that they are not too worried about or focused on any of the project deadlines!

As the project manager, you will want to ensure that team members understand their responsibilities. Using the simple three- step explanation above (find work, do work, update work) is an easy way to communicate this expectation. Making this commitment clear is something you may wish to do at the project kick-off meeting. You will also want to give team members a weekly rhythm to follow, for example:

• [Monday] Review the latest plan and your personal commitments (via dashboards or automated emails
• [Everyday] Do lots of work and make great progress!
• [Late Thursday] Make a progress update on your tasks and issues in the project site (if not already done
• [Friday at 10am] Weekly team meeting for 30 minutes. Team Member Responsibilities

It is a very positive and progressive step to talk to team members about the responsibility they are expected to carry on a collaborative project. In addition to the suggestions above, you can ask collaborative team members to have the courage to:

• Take responsibility given
• Contribute to the team
• Challenge the direction respectfully
• Accept the agreed team direction
• Participate in the speed of the project
• Alwaystakepositiveactions.

The Four C’s of an Ideal Team

The earlier chapter, ‘Cultivate Your Leadership Approaches (Models and Practices)’, offers lots of advice on selecting a team model for collaborative leadership. Repeated here from that earlier chapter is one suggestion for the ideal dynamics of a high performing team. You wish this atmosphere for your project team.

• Collegiate / Companions (friendly and enjoyable with no need for fear)
• Collaborative (on the one team and on the one project helping each other)
• Challenging (to each other – but respectfully) with the Conflict required for innovation. Be comfortable asking and answering uncomfortable questions.
• Can do attitude – and no such thing as I/we can’t.

Stage 4 – Track and Re-Plan the Project

Introduction

This chapter will take you through the steps involved in collaboratively tracking and re-planning your project. “There is nothing in this world constant, but inconstancy.” – Jonathan Swift (1667-1745), Irish poet, essayist, and cleric

The Essence

Why do we need to track and re-plan the project? Remember the advice cited earlier from the Prussian Army General when he said that no plan will ever survive the first encounter with the enemy?

What do we do in this fourth stage? We actively track and honestly re-plan the project with the team. It is quite difficult to do this sometimes, but it is that simple. This is what we need to do.

Track and Re-Plan the Project

As the team are working through their assignments, it is good to remember Murphy’s Law: “that which can go wrong, will go wrong!” There are some project managers I know who claim Murphy was an optimist!

Some tasks may be ahead of schedule, but almost certainly, some are falling behind. One thing you can be sure of is that the project is not running exactly to the plan you started with. That is why it is called a plan! Allied to this, other unanticipated problems or issues may have emerged. This fourth stage will help you understand three steps needed to track where the project is at, re-plan, and communicate the newly adjusted plan.

• A. Check and understand the project’s progress
• B. Find and manage exceptions (e.g., issues, risks and change requests)
• C. Re-plan the project.

A. Check and Understand Project Progress

By fair means or foul, you need to figure where the project is before you can re-plan, or before you and the team re-plan together. You need to know which tasks are ahead of schedule and which tasks are falling behind. Below are three simple ways that you can get this information.

i. Virtual Check

This is “collaborative project management” so be careful not to waste time asking people for basic project information that they have entered into a collaborative project site. Rather than calling everyone for a status update, you should be able to examine the various (project, issue, work, resource) reports, notebooks, and conversations on the collaborative project site you set up.

If your team members are following the simple guidelines in Stage 3 of this guide (“Work the Project”), you will have plenty of project updates to review from the comfort of your own desk. A sample set of reports to review in any project site might be:

• Home page to get a quick project status
• Overduework
• Work by assignee
• The full task list (in a Gantt or Kanban view)
• Resourceutilization
• Issues
• Status of your own work!

ii. Individual Check

MBWA – ‘Managing by Walking About’ is one of the oldest forms of management. Walk about, phone about, and talk to the team members and customers to get their take on the project status. Remember – this is collaborative project management, so your team members will expect you to show up, in person or virtually.

iii. Team Check

You do not want to have project meetings for the sake of meetings, so you do need to be careful with how these meetings are managed. I hope that you found helpful ideas in the “Manage Meetings (Ten Suggestions)” chapter earlier in this handbook! Here is a sample six-point agenda that you as a new project manager might consider for your team meeting:

• a) Check-In to see how your team members are doing
• b) Status and Health of the Project
• c) Issues: Review, discuss and resolve (as far as possible) open issues. Project meetings can easily get derailed and run over time, so it is key to use the time to solve problems as a team. Not all issues will be resolved at the project meeting but discussing issues will open them for further deliberation.
• d) Next: Look at upcoming tasks. It is good to look at what is up next. It makes people aware and helps them focus on the essential upcoming work. While the team is together, it is a good time to get the varied inputs of team members on key tasks scheduled to start soon.
• e) Achieved: Look at tasks achieved recently or at least the milestones. Many project meetings over-run in my experience! You need to be a really organized and disciplined facilitator to have meetings start and finish on time. If you know that project meetings will over-run, you should not start the meeting with this ‘historic’ item as team members will tend to enjoy talking about what was achieved last week, and this may eat most of the meeting time.
• f) Other Business

While you need not follow this agenda, it is important to have some sort of standard agenda or meetings will not be energizing or effective. You want meetings to be both. “There are only two qualities in the world: efficiency and inefficiency; and only two sorts of people: the efficient and the inefficient.” – George Bernard Shaw (1856-1950), Irish writer, dramatist, and critic.

B. Find and Manage Exceptions

You know where the project is at after this last step (‘Check and understand the project’s progress’), but do not start re-planning just yet! You should now check for outstanding exceptions. The exceptions on a project may come in many forms but issues, risks, and change requests are the most common.

You will want to resolve any open issues you can to remove roadblocks to the schedule. It could be that the issue’s resolution changes your plan. Similarly, look at open risks and decide if you need a mitigation plan to reduce the likelihood of the risks transpiring. In some cases, what was once a risk is now a reality, and contingency steps are now necessary.

You may also need to process project change requests, which often means consulting with team members and possibly project sponsors to see what course they advise and authorize. Approving a change request can impact your project, so best to know this impact before you start the re-planning in earnest. As a new project manager, it is important not to be afraid to make adjustments.

“Like all weak men he laid an exaggerated stress on not changing one’s mind.” – William Somerset Maugham (1874-1965), English writer, dramatist, and physician.

C. Re-Plan the Project

Some project managers are natural re-planners and do this daily as the project progresses. Others are so busy, re-planning itself needs to be logged as a project task. Styles and personalities come into play here. Some people embrace change and love re-planning and some decidedly do not!

Here are three sub-steps you might consider for this re-plan step, whether you do it as necessary or at a set time every week:

• i. Re-assign Work and Send Notifications
• ii. Report to and Work with the Appropriate Stakeholders
• iii. Tailor the Project Site as Needed.

i. Re-assign Work and Send Notifications

By this stage, you have gathered enough information to re-plan the project. In reality, you were making some adjustments as you executed the preceding two steps, but you need to perform the remaining changes before you formally re-publish and re- communicate the plan.

• a) ProjectRedefinition: The project is defined and laid out in a series of artifacts, e.g., project statement, tasks, issues, etc. Updating these can be as simple as traversing the lists in the project site and making adjustments.
• b) Project Re-Assignments: If the structure or workloads of your project have changed, you will need to reassign work to different team members. At this stage, you should also find and fix any over assignments.
• c) Notifications: Check that the changes are still going out through the notifications mechanisms set up earlier in “Stage 2 – Plan and Setup the Project”.

ii. Report to and Work with the Appropriate Stakeholders

Now that the changes are made, you may need to update your stakeholders. Your project sponsor will need to know what changes are afoot. It is best that this news comes directly from you, the project manager. If the news is bad, do not be afraid to take this step. It is important. Working with your project sponsor may involve some of the following:

•  Deliver periodic status reports (printed, emailed or verbal)
• Raise exceptions including project change requests, top issues, and top risks
• Resolve sponsor level issues and apply the resolution through project re-planning (if appropriate).

iii. Tailor the Project Site

In “Stage 1 – Initiate the Project” you decided how best to manage the project. As the project progresses and naturally changes, you may have to change how you manage to match the evolving needs of the project. Maybe you opted not to manage risks very formally at the outset, but you now believe that the project is changing at a pace that is not healthy, so you now need to introduce more formalized risk management. Alternatively, perhaps you initially decided to manage with issues, risks, and change requests but now realize that this was too much project management for this project. In this case, you scale back the amount of project management you use.

As you periodically re-plan the project, you will do well as a project manager to ensure you have ‘just the right’ amount of management for the project in hand. At this stage of the process, you can tailor the project approach and site to mimic the desired amount of collaborative project management.

Stage 5 – Close the Project

Introduction

This chapter will guide you through how to benefit from an orderly close to the project with your team. “There must be a beginning of any great matter, but the continuing unto the end until it be thoroughly finished yields the true glory.” – Sir Francis Drake (1540-1596) English navigator

The Essence

Why formally close the project? By definition, a project has a start and finish, so it needs to be closed out. If you do not shut it down who will? In the immortal words of Francis Drake, this is where you get the glory! What do you do in this stage? You and your team will learn from the project as you close the project together.

Close the Project

As stated earlier, we can depict project management as follows:

With this in mind, much of the project is about working the project, figuring what is happening, and periodically re-planning to ensure the end goals are met. Health warning! Project Management does require a determination to keep going to the end, as there will be difficult periods on most projects. The earlier Sections 2 and 3 of this handbook include many suggestions relating to physical and mental wellbeing, and personal and situational leadership to help you overcome these challenges.

There comes a time when the project needs to be shut down. As we know, one of the hallmarks of a project is a defined start and a defined end. This is what marks a project out from processes and continuous operations. A set of steps for an orderly project close stage is as follows:

• A. Close out the project site
• B. Run project post-mortem and track lessons learned
• C. Capture any useful modifications made to the project site for use on future projects.

A. Close Out the Project Site

On an administrative note, you now have a live project site for a project that is just finished. At a minimum, you should mark the project closed so that anyone who visits the site can quickly see that the project is completed. You also want to ensure that the project does not appear in any current reports going to senior management. It is usually best not to fully archive and hide the site for a time. Normally when projects are completed, it is really hard to get any information about them after a few months. The half-life of project information is very short! It helps to look back at similar project sites when planning new projects.

B. Run Project Post-Mortem

No project ever goes perfectly. None! If you consider the approach advocated in this handbook, we have suggested that you have regular tracking and re-planning steps. This is essentially a tacit admission that we are learning as we go on every project, as indeed is the oft-recommended use of the “Start|Evolve” approach to collaborative project management.

If we can learn as we go, then why not learn as we finish? There is a tendency to take flight when the project is over and move to the next one. However, the more you learn from the project you have just completed, the more successful you will be with the project you are about to start.

Remember this handbook is written primarily for “accidental”, “occasional” or new project managers. These project managers generally have no formal training and few experiences managing projects, so any learning opportunity should not be wasted! It is also important to remember that as a project manager, we have been a leader of the project, but not the sole owner of its processes and tasks.

With this in mind, it is respectful to ask team members what they thought of the project. Many project managers say they do not have time to do project post-mortems. However, the same professionals seem to have time to fall into the same traps and then spend time fixing the issues. A stitch in time saves nine! “It is a capital mistake to theorize before one has data.” – The Adventures of Sherlock Holmes (1892)

Very switched-on project managers and team members will be keeping a list of items for the post mortem as the project progresses. It can be very helpful to host the post mortem in a different and relaxed setting – perhaps away from the office – or maybe in the office with some nice snacks served. This change of location or setting can help the flow of feedback.

To do a good post-mortem it is helpful to have a set of open questions to ask. Questions naturally help the participants reflect on the project from various angles, so the quality of feedback and learning is best. A sample set of simple and open questions include:

• What went well on this project?
• What did not go so well on this project?
• What did we not do on this project that might have helped?
• What specific actions should we take to adjust the approach to the next project we do as a team?

Team members are very smart, so the real goal of this step is to give people the time and the space to reflect on the project. This step can be carried out simply enough once the time is set aside. A set of possible mechanisms include:

• Meeting: The team meets to talk through the project in a facilitated session. 
• Survey: You give people a survey to complete.
• Meeting and Survey: You do a combination of both; people answer questions in advance and then attend a meeting to thoroughly discuss the survey answers and make some recommendations for future projects.

On larger projects, you can run a “Lessons Learned”/ “Review” exercise modelled on this post-mortem at the end of each project stage.

C. Capture Project Site Modifications

If the collaborative project site was modified as you went through the project, you will want to review the adaptations and apply those approved to the template used to create new project sites. This is a very pragmatic and efficient way to improve your approach to project management.

Build your Own Approach

Now that you are this far through this Personal and Collaborative Leadership handbook, it could be helpful to reflect on how you might manage your projects. Below are three summaries of the stages and steps presented in the preceding chapters to help facilitate this process for you. “Whatever good things we build end up building us.” – Jim Rohn (1930-2009) American entrepreneur, author, and motivational speaker.

Low Adoption

Perhaps you just use the five high level stages as your guide:

1. Initiate the Project
2. Plan and Setup the Project
3. Work the Project
4. Track and Re-Plan the Project
5. Close the Project.

Medium Adoption

Maybe you use the five high level stages and some of the three steps in each stage as your guide:

1. Initiate the Project: A. Get the Project Approved, Sponsored, and Resourced. B. Decide a Project Management Process. C. Create a Collaborative Project Site
2. Plan and Setup the Project: A. Plan the Project. B. Desk Check the Project Plan. C. Notify the Team of their Responsibilities
3. Work the Project: A. Find Work. B. Do Work. C. Update Progress on Work (recording any issues)
4. Track and Re-Plan the Project: A. Check and Understand the Project’s Progress. B. Find and Manage Exceptions (e.g., issues, risks). C. Re-Plan the Project
5. Close the Project: A. Close Out the Project and the Project site. B. Run Project Post-mortem and Track Lessons Learnt. C. Capture any Useful Modifications (made to the project site for use on future projects).

High Adoption

You may wish to use the five high level stages, some of the three steps, and some of the associated sub-steps as your guide, when building your own process / approach:

1. Initiate the Project

• A. Get the Project Approved, Sponsored and Resourced
• B. Decide a Project Management Process
• C. Create a Collaborative Project Site

2. Plan and Setup the Project

A. Plan the Project

• Complete the Project Statement
• Define and Allocate Tasks
• Add the other Project Artifacts Needed
• Assign the Work

B. Desk Check the Project Plan

Work the Time-Quality-Cost Trade Off

C. Notify the Team of their Responsibilities

• Host a Project Kick-Off Meeting
• Enable your collaborative site with the facility to email notifications on all new work assignments
• On your collaborative site, setup an easy to find “My Work” report / dashboard
• Setup scheduled emails with nudges for upcoming or late work.

3. Work the Project

• A. Find Work
• B. Do Work
• C. Update Progress on Work (recording any issues)

4. Track and Re-Plan the Project

A. Check and Understand the Project’s Progress

• Virtual Check
• Individual Check
• Team Check

B. Find and Manage Exceptions (e.g., issues, risks)

C. Re-Plan the Project

• Re-assign Work and Send Notifications
• Report to and Work with the Appropriate Stakeholders
• Tailor the Project Site (to match the evolving needs of the project)

5. Close the Project

• A. Close Out the Project and the Project site
• B. Run Project Post-mortem and Track Lessons Learnt
• C. Capture any Useful Modifications (made to the project site for use on future projects).

Collaborative Project Management Leadership

It goes without saying that leadership is required to successfully deliver an amazing project, but what does this mean in practice?

Personal Leadership

(reference Section 2 of this handbook): The entire project team, and especially the project manager, need to be at their best and will ideally bring their ‘A game’ to the project. The team need to be in a good place personally and this, while desirable on so many levels, does not happen by accident. This requires investment and personal management in areas such as energy, attitude, awareness, personality, and time-management. As it happens, this level of personal leadership also develops the same practices and habits that lead to a happier and healthier personal life.

Situational Leadership

(reference Section 3 of this handbook): A project team encounters many common repeated situations, including various types of meetings, decisions, variable performance, awkward communications, unclear roles, and responsibility lines, etc. It is helpful and important to have patterns, practices, and protocols to successfully manage these recurring situations.

Collaborative Project Management

(reference Section 4 of this handbook): The world is evolving to a place where more and more of our people want, deserve, and are being given project leadership responsibilities. In many cases this responsibility is not accompanied by line management authority, nor does it need to be. This ask or grant requires that each person have leadership approaches that they can call on, and that these approaches are adaptable and compatible with the requirements of collaborative project management. It is also important that the organization develops project and team models designed to accommodate and encourage these higher levels of leadership.

Process Management

Introduction

The prior chapters in this Section 4 focus on project management and more specifically on the process of collaborative project management. This last chapter in this section, in six pages, explores the nature of processes (starting in 1776!), and process improvement. Exploring process management is not for everyone, though I find it very interesting and relevant, but as with all chapters feel free to skip for now and come back later as you wish.

The Essence

A project is a temporary, one-off endeavor with specific objectives. A process can be defined as a series of repeated actions that produce something or lead to a particular repeatable result. Understanding the difference between a project and a process will help you to apply the right approach to upcoming work.

Definition of Process

In 1776, Adam Smith wrote “An Inquiry into the Nature and Causes of the Wealth of Nations”, and as a result, the poor man is often blamed for creating modern day capitalism! Consider the following description from the first few pages in his book and ask yourself: is this a project or a process?

“One man draws out the wire, another straights it, a third cuts it, a fourth points it, a fifth grinds it at the top for receiving the head: to make the head requires two or three distinct operations: to put it on is a particular business, to whiten the pins is another … and the important business of making a pin is, in this manner, divided into about eighteen distinct operations, which in some manufactories are all performed by distinct hands, though in others the same man will sometime perform two or three of them.”

As I am sure you have guessed, the making of pins in this manner is definitely a process. However, the initial set up of the pin factory is a major project. Subsequent improvements or modifications to the factory might also be treated as projects.

Process Improvement Models

If you are serious about implementing and improving project management across a group, a knowledge of process improvement models can be very insightful and extremely helpful.

The Deming “PDSA” Model

W. Edwards Deming, an American quality expert, was brought to Japan in the aftermath of World War II to help in the reconstruction of the nation. Deming had been influenced by the Shewhart cycle from 1939 and brought what was later called the Deming wheel to Japan in 1950. The Deming wheel was depicted as PDCA (Plan, Do, Check, Action). Deming himself later changed the cycle to PDSA (Plan, Do, Study, Act). In later years the Plan, Do, Check, Act or Plan, Do, Study, Act cycles have been used as instruments of continuous improvement for processes. They have been famously associated with the Japanese quality assurance, total quality control, and continuous process improvement movements.

These simple but powerful cycles can be very helpful in improving project management in an organization. Think of it in the following generic and repeatable terms:

• Plan the process change you want to introduce
• Do or implement the process change
• Check or study the impacts of the change
• Act on this to make any adjustments that are appropriate.

And some time later start the cycle again, so the cycle of improvement continues. If a group uses PDSA properly, the group is systematically in a constant cycle of very positive continuous process improvement.

ISO 9000 Series

The ISO 9000 series can also be very powerful for process improvement. The essence of the ISO 9000 series is that you, in an intelligent way, decide what you are going to do and write this up as a set of policies, procedures, and standards. You then train everybody in the enactment of these approaches. And finally, you continuously check how you are doing against that which you said you would do. These continuous checks include audits and associated corrective actions (arising from the audit findings).

It is possible to use the ISO 9000 series either as a mechanism for improving quality internally and / or to get the quality of your process assured by an external agency, which would result in the award of an ISO 9000 certification for your process (but not your product).

The CMM – Capability Maturity Models

To round out this brief introduction to process improvement models, it is worth adding a short explanation of the Capability Maturity Model (CMM). This model came out of work facilitated at Carnegie Mellon University in the late 1980s. The work is sometimes much maligned because, as with all models, it can be abused by people who want to prove they are better than they really are. However, the essence of the model has some really excellent thinking.

The model is essentially a five-level model, and any process can be at any one of these levels.

1. Initial: Level One is characterized by being chaotic or informal. You could say that all processes are at least at Level One!
2. Repeatable: To say that a process is repeatable means that it can work pretty much every time. However, it tends to be overly dependent on the heroics of a small number of people to make it so. If these people leave the organization, the process would more than likely fail to deliver the intended results.
3. Defined: At this level, there is a thought-out and documented step-by-step set of policies, processes, procedures, and work instructions, and ideally, tools to automate some of the steps. The idea is that new people can come and go, and the process will guide whoever is involved in that particular process. Of course, there is an implicit assumption that people have to be trained and capable of executing the process, but the process is at least defined.
4. Managed: Here, the process has a high degree of management oversight, is instrumented, and measured. With these metrics, we know where we are at. We might not always like it, but we will know how the process is performing.
5. Optimizing: Finally, Level Five, is called Optimizing. Note that it is not called optimized as this would indicate an end point. Processes are dynamic, and as such, we need to tweak and optimize them from time to time. The practice here is to use the metrics and other information to make decisions to implement as process changes. In earlier levels, we have basic checks in place, and we make changes because we think or believe they make sense. But at Level Five, metrics and data are also guiding us intelligently to make changes.

Can you see how this CMM might apply to the process of project management in your organization? Maybe you can decide what level your project management process is at. Is it Level One, Two, Three, Four or is it at Level Five? Identifying this current level of project management will help you decide what investment comes next on your collaborative project management journey.

REP versus PDSA, ISO 9000, CMM

In Section 1 REP was presented as a personal change management process. This chapter presented PDCA, PDSA, ISO 9000, and CMM as organizational process improvement models. I am sure you can see the overlaps and similarity of thinking.