Rich, B.R. and Janos, Y., Skunk Works, Little Brown and Company, New York, 1994

I have had this book in my library for quite some time and although I've browsed it before, I recently had the opportunity to actually read it. Why I didn't read it earlier, I just don't know because it is just so full of stories and wisdom on many levels.

For those who don't know - the Skunk Works were (are still?) a top secret Lockheed shop for the design, development and manufacture of advanced and innovative aerospace systems. If U2, SR-71 Blackbird and stealth planes mean anything to you - then this book tells their story.

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

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.

This is yet another article in The Australian newspaper on the problems and issues around the Federal Government's schools and education stimulus package. Assuming the facts are right, and I have no reason to believe otherwise, the waste is just incredible. Good on the parents and staff to say they will hand the money back as it is just replacing a perfectly functioning building with another building serving the same purpose....on top of all the disruption that it will cause.

Milton, 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.

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?

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.