This brings me to addressing how to develop a process, in this case in the context of project management. The single most important rule in developing a process is to focus on "value". Value is the centre of the process .... quite literally.

Step one in any process definition is to identify what the end result has to be. You then determine all the relevant steps or tasks to get from where you are now, or the beginning, to the end .... focussing ONLY on those steps that add value .... that get you closer to your goal.

I have a number of skills in a number of areas and have a few topics around which I can talk for 40 mins or 1-2 days!! You may consider them to be a bit eclectic and not really connected .... but in fact they are all connected through my project management, business investment and general management experience. All of them are well grounded in my personal journey ....good and bad!

I am mostly engaged through my consultancy firm HolisTech® Pty Ltd or my investment firm Padden Industries Pty Ltd, but I do have relationships with companies and businesses big and small through which I sometimes sub-contract.

This adds to my entry on Project Interviews.

I wasn't going to use more than one set of meters or graphs for a project, but the field is so full of challenges and interesting nuances, that I couldn't resist. It may not be last one either.

So I have added a second page of meters for the interview making for eight in all.

I am about to start my interviews with project managers and hope to continue them for a long time and perhaps revisit the project over the period of its existence to see how it is progressing.

But before I start to blog the interviews, I need to set the scene because I ask them to complete a very short survey and to complete a "chart" of their project's "rhythm" over time and these need some explanation.

To follow on from "The Project Knowledge Elephant (01)".

When it comes to "seeing the elephant", it is best to see it early or if you can't do that, to respond to it as you see it.

I was asked a question in an online survey today that got me intrigued as to why it took the approach it did.

Here is the question......

In your opinion, what is the most important aspect to project management - scope, schedule, cost, quality or communication?

In this next few blogs, I intend to explore my Project Knowledge Model (PKM) in more detail but rather than 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".

You may recall the ancient parable or tale of the blind men and the elephant. According to Wikipedia there are a number of versions from different cultures.

I said in a previous blog (The Value of a Program of Projects) that projects are a way of ".....pulling one or more of the levers of revenue, expenses or investment in a "controlled" manner. Because projects are a deliberate and "controlled" mechanism that supports proper governance with defined expenditure, risks, schedules and outcomes or benefits."

I just wish to provide more insight into what I have said.

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.

But what is the impact on the program of taking such an approach. Well, if we look at the below diagram, we have two Vehicles separated in time:

=   Vehicle #1 goes from 2010 to 2012.
=   Vehicle #2 goes from 2014 to 2016.

Both these Vehicles are impacting in some way, the one System - in this case a Facility System.

Doing this across multiple Vehicles and Systems means we have a program of projects with various Vehicles and Systems. We can also see this another way as a pool of Vehicles creating or changing a group of Systems.

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.

What I am saying is that some sort of "Vehicle" should be used to create or change a "System" ....to move it from one state to another state. Accordingly, a Vehicle manages the transition of a System from an existing state to the required state.

Additionally, from what I can see, project management is not really an accepted "management" discipline. Although, there are some moves by the various project management bodies and professional associations to get project management recognised as a profession. Additionally, the PMI recently released some of its research into the value added by project management. I think all of these are laudable and appropriate. But there is a hitch I think.

This is where project management I believe has it slightly wrong. It is taught as a disjointed independent set of activities and products and not as a flow or mesh or weave of activities and products.

In this case if something is out of place it immediately becomes apparent because it can be "seen" or "heard" just as a wrong musical note in a melody can be heard to be incorrect as it disrupts the flow. Conversely, it is difficult to "hear" or "see" something out of place in hip=hop as there is no melody in which to gain that insight.

The other issue I have with project management in general is that there is no universal model that incorporates different ways of doing things depending on the situation.

For example, at a macro level, there is an inability for PMBOK and PRINCE2 to accommodate the agile methods. To me this means that the good points from the agile methods are not necessarily easily slotted into a non-software project. Indeed, the reverse can be true too.

This musical metaphor I think goes further.  For instance how do you know when the wrong tune is being played?  What does the chorus represent and although this undoubtedly is not new ...what does the conductor represent?

Let me start by saying that I have a bit of a problem with the PMBOK and PRINCE2 frameworks. It is not that they are not useful or full of good ideas, it is just that they are ...... well ... "blocky".

Strange thing to say but let me try to explain.

I am exploring a number of concepts under an eclectic collection of
subject areas. I am also exploring some of these in my blog about small
and medium enterprises and micro-businesses at Lukim All. Undoubtedly, I will add to these in time.

Formal. Pat is a very experienced program and project manager with a strong academic background in the profession which includes post graduate project management qualifications. He has a significant and current consulting and business background with a particular strength in communicating complex concepts in simple and pithy ways including discussions, presentations, blogs and papers.

Informal. I am the normal family man - wife and two daughters, two dogs (german shepherd and golden retriever - stupid and cupid as the kids call them!), a stack of frogs in the gardne and a visiting family of magpies (a native Australian bird that is quite at home in the urban environment).