Tagged ‘governance‘

Now this is a roadmap…

Five Corner Stones of PM

Today I was asked a question, that can be summarised into a version of “How do you define Project Management?”

After giving what I considered to be a decent response, I wondered, if asked again what five things would I want to mention. Without much consideration or deliberation I grabbed the PMI BOK (even though I’m more a PRINCE2 practioner myself) and extracted five points. Oddly the one thing I always personally equate project management activity to – Risk Management – didn’t make the cut. Who cares (sic).

Lets start with what an organisation should do with respect to setting up a Project Management practice/process. Its important the organisational structure understands the concept of a Project – that is to say a transient structure that comprises separate disciplines and brings them together to achieve a purpose and then disperses them.

If the organisation is based around value created via projects, then its important it emphasises an organisation that is Project Led. If the organisation is not really based on value via projects, but merely uses them sporadically, it doesn’t need to

Project org

In a matrix setup, the project needs a clear leader, the PM. Anything separate to that, say a Staff from a functional area, and you end up not having a project led organisation – which would naturally imply everyone else has ‘other non-project work’ to do.

Transient Group

Once you have an org structure that facilitates the correct level of project engagement and execution, you need a project method. This method should cover at the very least three aspects of Plan What To Do, Do It, Control the Plan in the face of Change. It would be brave, perhaps, to try to ignore the need for a well documented and shared method. Furthermore, it would be foolish, definitely, to not expect the plan to require change control as the world acts against it.

Setting up

Concerning what the project does, thats a matter of Scope. Typically (and conveniently ignoring the agile debate), the scope would initially be fixed and should be broken down into deliverable chunks. What is a chunk? At the very least it is something that you can apportion a budget to, can track and trace, and can essentially confirm as complete in isolation to the bigger picture.


So now you have (i) an organisation that knows how projects fit into its mission/purpose, (ii) has a organisation structure aligned to that, (iii) a method that the PM and team can understand and follow to setup, plan, and control a project,  (iv) a clear understanding of how to define a scope of a project such that you can manage delivery of it. What is left?

Well, unless you are a charity with endless funds and benefactors, you need to manage money and ultimately manage projects to make even more money for the organisation. It is imperative that the entire organisation is clear on how the projects make money for it whilst delivering value for the end-result (be it deliverable, customers, internally or externally).

This little table summarises some of the very simple basics that help you know where the money is coming and going. This is, at core, the financial governance of a project – which is not the only governance, but a critical part when it comes to shareholder value.

Show me the money

I’ve ignored the whole agile debate here, as to me agile is a sub-method in some cases that is focused on software development. The agile manifesto initially stated that formalised rigid projects would not allow for rapid incremental software delivery. Almost every enhancement to the software process has delivered value, it is hard to say if Agile is a panacea, to me it is just another enhancement that like the others has pros and cons.

The Agile Manifesto is radical to those who consider structure and discipline to be essential in making money. Just have a look at what it actually says:

We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

 Yet, when it comes down to it:

  • If when you have thousands and thousands of lines of code and no architecture blueprint or design principles to reference, whether you’d enjoy the prospect of quoting how much to change the way it fundamentally behaves and explain it succinctly;
  • If you are a software delivery house whether your customers or you would want to do any substantial financial business over a handshake and a nod, and not have any contracts defining any sort of liability clause or ownership of IPR;
  • If you were agile whether you’d be able to embark on the unknown and risk company brand and cash flow/balance, without an inkling of a plan of how you’d make money out of it and minimise risk.


That is to say, whilst there is value in the items on the left, the items on the right are not yet the normal way to do business even in software development based organisations. It is not to say, in a few weeks, months, or years it will not be – just not yet.

So would I change the five cornerstones? Probably, after all, I’m now able to respond to change and adjust my original plan 😉

The Perils of Outsourcing…

Received an email from LinkedIn today – the first paragraph said this [my highlights]

We recently became aware that some LinkedIn passwords were compromised and posted on a hacker website. We immediately launched an investigation and we have reason to believe that your password was included in the post.

Oh dear! So I read on to the second paragraph

To the best of our knowledge, no email logins associated with the passwords have been published, nor have we received any verified reports of unauthorized access to any member’s account as a result of this event. While a small subset of the passwords was decoded and published, we do not believe yours was among them.

Phew. No wait. Hmmm. Let me try that again. I re-read the first paragraph -Oh Dear- then the second on paragraph -Phew-. Man I’m confused.

Then I read on

The security of your account is very important to us at LinkedIn. As a precaution, we disabled your password, and advise you to take the following steps to reset it. If you reset your password in the last two days, there is no need for further action.

Oh I see, this is a phishing scam. Nobody at LinkedIn would write that incomprehensibly….would they?

How funny. Real or not, it highlighted how real customer service is about how companies behave when there is an EXCEPTION to the flow. When things are fine, we can all rave on about everything and anything. It is when something goes wrong that quality really comes to the fore.

In this instance, I have to say it is sorely lacking.