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.

Essentially, I would maintain that in these scenarios (see Evidence and Project Management (01)), project managers are making "claims", some even "vague claims", about the state of their project.

That vague claim is made in the spirit of getting the boss off your back or in the knowledge (perhaps mis-directed) that by the time anyone checks ... the project will be where they have reported it to be anyway! It is done with good intentions.

I have called the approach I prefer to use for project management an "evidence based" approach. So it behoves me to define this in some way.

I am not saying that project managers per se do not use evidence to understand their project. I just don't believe there are comprehensive approaches to that evidence base and I believe there is waaaay to much emphasis on the governance side of things, but that is for another blog.

This is the third in my series on scheduling (I spoke about the knowledge required to successfully schedule in my last blog) and I would like to cover what I perceive as the two broad ways schedules are used - namely for planning and/or managing an effort.

One way I have seen a schedule used is to identify some key dates and milestones toward which the person or team attempt to work. Reactive adjustments are then made when a review is required or a further estimate is needed. In other words, scheduling is used to do some initial and periodic planning rather than used to manage the ongoing effort.

My experience tells me that knowledge issues in schedule management fall into a number of broad areas:

=  understanding the concepts,
=  understanding the tools,
=  long term versus short term planning,
=  estimating and measuring, and
=  risk.

The schedule and responsibilities for the schedule is one of those "chorus" elements I spoke about in an earlier blog called "A Melody not Hip=Hop (02)". This is what I said:

Singing the chorus could represent the things you do often in a project such as risk management, schedule management, cost reviews and so on. It's an interesting concept having a "chorus" in a project. A chorus is the part of a song everyone gets to know and bashes it out with gusto when it comes. From my memory, it is also the part "everyone" sings. So why can't there be a "chorus" in a project. For example, there are aspects of project management that are the responsibility of everyone in that project. The management of the schedule, cost, quality and risk are four that come to mind. These aren't the responsibility of a few. These are the responsibility of all and should be sung regularly throughout the life of a project.

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.

Humphrey, Watts, S., Winning with Software: An Executive Strategy, Addison-Wesley, Boston, 2002

The message here is that if you wish to develop good software, particularly of any significant size, you need a robust process and a team of disciplined programmers/engineers. The operative words here are robust and disciplined. These two terms, particularly the discipline one, resonate particularly well with me, because one of the significant causes of a problem project is the lack of discipline to follow a defined process. The further message is that "quality counts" - even more so than schedule. This is particularly relevant to any business that uses software.

I want to talk about trust in this blog. I have had my trust betrayed on a number of occasions in both business and within projects. I have also had it tested and have been shown great trust by business colleagues and friends.

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.

This concept can be viewed another way - as a chronology or evolution of systems. A system enters its life at some point in time. In the below diagram some have begun their life prior to say, 2006. Others entered their life after 2006.

You will also note that the system will commence life as being in use (green), then at some point start to degrade (yellow), then become critically degraded (light red), until finally it is obsolete (red).

Many project management books and texts (and perhaps blogs) start with a definition of a project. Or if not, it is certainly in there shortly into the book. But why is that?

Well I guess they all need to put a boundary around what they are talking about, but also because it is pretty useful leading into the wider part of the text.

I am no different in that sense because I do need to answer that question "What is a Project?". But I think what I am about to say is different because the way I define a project is different to what you might find in the more traditional texts.

So ... what is a project?

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).