Political correctness is tyranny with manners.

— Charlton Heston
(1923-2008)

KM

Project Knowledge Sectors (02)

To continue with the Project Knowledge Sectors discussion from Project Knowledge Sectors (01). From these Knowledge Sectors we can now derive an understanding of the overall Project Knowledge Model (PKM) and how it "flows" together no matter whether it is the Vehicle or the System.

Project Knowledge Sectors (01)

In my blog The Project Knowledge "Elephant" (02) I said:

If we accept that "knowledge" of the system and vehicle, and so the project, is essential to a successful project, then we can start to get a better understanding of a project by looking at what "knowledge" is required.

For this I use what I call the Project Knowledge Model or PKM and I am going to explore some of its broader concepts in this next series of blogs.

I wish to start that explanation of the Project Knowledge Model (PKM) here in this blog.

Atomic

Book – AtomicCamrass, R. and Farncombe, M., Atomic: Reforming the Business Landscape into the New Structures of Tomorrow, Capstone Publishing Limited, UK, 2004

Atomic attempts to identify the future business construct based upon trends identified today. Camrass and Farncombe take the analogy of an "atom" that can become part of larger molecules to form value adding business structures. These are more agile and focused organisations than the monolithic businesses today.

The Project Knowledge “Elephant” (02)

When it comes to "seeing the elephant", it is best to see the elephant early rather than late such as in the "big bang" approach to requirements definition and system development. If you don't see the elephant early then you need to have mechanisms that permit you to quickly respond to the elephant as you see it. This is epitomised by the agile software development processes.

KM for Teams and Projects

Book – KM for Teams and ProjectsMilton, N, Knowledge Management for Teams and Projects, Chandos Publishing, Oxford, 2005

This book started slowly for me. But once I could see where Nick Milton was coming from, quite a few things "clicked". Being a project and program manager myself, some of his concepts resonated tremendously and I will implement them in some of the areas I work in including some of my clients.

The Project Knowledge “Elephant” (01)

In this next series of blogs, I intend to explore my Project Knowledge Model (PKM) in more detail but rather at the program level as I have in my previous blogs, this is at the project level. It is a model of projects that permits a "melody" of knowledge/information constructs that in turn provides an insight into the anatomy of a project.

The first item on the agenda is understanding what I call the "knowledge elephant".

The Value of a Program of Projects

One of my goals in life is to illustrate the value of projects to the general management fraternity. Perhaps more accurately, explaining the value of project management to executives. For a number of years now I have been "monitoring" the level of acceptance of project management into the broader management community. I do this by looking for project management books in the management "guru" sections of bookshops. I must say .... I am yet to find one devoted solely to project management. Normally the project management books are in the IT section or the academic sections. It's an interesting "index" which I have started to call the "PM guru status" index.

Doing “Program Management”

I have often seen "program managers" simply manage a group of projects by overseeing each of the projects in their program. They act as a sort quality control of the project outcomes and perhaps oversight the scheduling and financials of each of their projects. In some cases they are more a hindrance to the progression of a project as they place a layer of bureaucracy over the project staff rather than a layer of coaching or mentoring or assistance.

Viewing the Program

Let's now look at doing this across many instances.  Doing this across multiple Vehicles and Systems means we have a program of projects with various Vehicles and Systems.

Allocating a Vehicle

Moving on from Defining a Project. If we are to look at the Vehicle in a bit more detail we can see that it should follow what might be called a classic "project" process. Something like the below illustration where it has distinct phases leading to closure. In this case a simple Initiate, Plan, Execute and Close.

Syndicate content

Welcome to Knowing Projects

A Place to Explore Project Management Concepts