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.

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.

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.

A Strategic Risk Based Approach to Regulating Technologies and Vulnerabilities based on HolisTech's® Regulatory Framework presented at the 2007 International Symposium on Technology and Society (ISTAS`07), titled Risk, Vulnerability, Uncertainty, Technology and Society, at the University of Nevada, Las Vegas, USA in June 2007. Co-authored with Graham Durant-Law.

The paper outlines a strategic risk based approach to regulation based on the generic regulatory system developed with the participation of nine of Australia's premier regulatory organisations. The result is a generic strategic management paradigm of regulation and the various behavioural interactions that regulatory systems may utilise. It includes regulatory strategies that may be employed to influence how organisations and people behave, as well as other aspects of regulating, including regulatory metrics, regulatory types, and the mechanisms of regulation. The generic nature of the framework provides for its application in almost any context and to any objective. It also provides for a top-down strategic approach to risk management, an unfortunately all too rare occurrence.

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.

Bennett, W. and Crawley, S., Wayne Bennett - Don't Die with the Music in You, ABC Books, Sydney, NSW, Australia, 2007.

I have this question I ask at dinners/lunches which is "If you could have any three people as dinner guests who would you have?" with the variations of dead or alive or alive only or politicians or sports people and so on. It can sometimes give you an insight into the person, but it always throws up surprises as often they are an obscure person. I am shallow enough to admit that Elle McPherson is always on my list (because she is an inspirational business person ... duh!!). BUT ...the other one is Wayne Bennett and I often change the third person.

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 attended this presentation quite some time ago last year and blogged about it at the time. But then my site went pear shaped. It is worth putting it up though. Michael Schaper had some interesting facts to discuss. So her is my original blog entry.

Along with Donna Cox of Mantra Training and Development, I attended the Canberra Business Council (CBC) (of which HolisTech® is a Corporate Member) and Australian Institute of Company Directors (AICD) luncheon. Apart from doing a little networking (not that I am good at that), we listened to an interesting presentation by Dr Michael Schaper, the Deputy Chairperson of the Australian Competition and Consumer Commission (ACCC). It was titled Small Business - Future Opportunities & Challenges.

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.

I was browsing the other night and again came across some comments on the Government 2.0 Task Force. It is an interesting initiative and I am uncertain as to how much it will achieve to be very honest. But nonetheless, it is inevitable in a democratic society and with the more on-line "savviness" of the younger generations.

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.

A while back, I was asked by a business colleague to assist in providing an insight into how an organisation could handle their knowledge asset better and how they could weave a network of advisors and small/medium enterprises.

After a couple of coffees and a long chat, he asked if I could encapsulate our discussion in a short brief. Always up for a challenge, I based the brief on the one hour executive briefing we (HolisTech Pty Ltd) provide to executives in Government agencies on leveraging Web 2.0.

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.

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.

Camrass, 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. To their credit, they try to identify those "atoms" rather than just generalise:.

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.