Category Archives: IT Project Management

Unscrambling Verification & Validation (V&V)

Verification and validation are processes that are used together to check that a product, service, or system meets requirements and specifications and that it fulfils its intended purpose. Our latest White Paper V&V = the Verification and Validation of Deliverables provides an overview of these important processes and:

  • Defines the purpose of each;
  • Shows how they work together to deliver quality to the client; and
  • Seeks to unscramble the different acronyms used by different people such as V&V and IV&V.

The White Paper is free to download from (no log-in or registration required).

Directing for Performance. The AICD moves beyond conformance.

The Australian Institute of Company Director’s (AICD) inaugural Australian Governance Summit 2016 focuses on ‘directing for performance’. The summit will explore beyond compliance to frame governance as a fundamental driver of performance outcomes.  A view we strongly support. For more information see:

The AICD have also identified a range of challenges and ‘disruptors’ that will affect organisations in 2016 presenting opportunities to organisations that can adapt and exploit the situation and threats to those who are slow. The vast majority of the threats and opportunities involve the rapidly changing digital economy which will require a radical change in the way most organisations integrate ICT into their businesses. Rather than being an enabler of business, in a connected world IT will increasingly be the business.

The Gartner IT Hype Cycle. See:

The Gartner IT Hype Cycle.

One of the major challenges for organisations of all types identified by the AICD is a chronic lack of IT skills among Board members, with many boards populated by Directors who believe the digital economy will not affect their organisation because that are in the (fill in the gap) industry, not the IT industry.  The simple fact of life in the 21st century is that it does not matter if you are in agriculture, mining, manufacturing, personal services or any other business the successful organisations will be driven by the creation and use of information. Successful organisations will be able to find and use the ‘right information’ from the ever increasing torrent of ‘stuff’ being generated minute by minute:

Internet minuteRecognising the challenges and opportunities is one thing, adapting organisations to benefit from the changes is another!  What’s missing from the AICD evaluation this year is a focus on the central role of governing projects and programs to deliver the performance outcomes. Every change needs a project or program to create the ability to change backed up by organisational change capabilities to realise value.

Governing for change is the focus of ISO 21505, a project I’ve been involved with for the last 6 years, due for publication late 2016. It is also the focus of the annual Project Governance and Controls Symposium (PGCS), held in Canberra each May; see:

The challenge for organisations of all types and sizes is to adapt their governance and management structures to exploit the rapidly changing world.

Project Industry Trends

A presentation by Jim Harrison of Itcom Australia Pty Ltd to the PMI Melbourne Chapter this week, focusing on project management trends primarily in the ICT and Finance sectors of the Victorian and Australian Eastern Seaboard economy. The presentation highlighted some interesting trends that would appear to have a wider implication and correlate with our experience and other sources of information.

The first key finding is that project management maturity is starting to develop. 80% of the organisations surveyed by Itcom had some form of PMO and most had a defined PM methodology; 30% based on the PMBOK® Guide, 30% on PRINCE2 and 20% an in house methodology. The trend over the next few years is likely to be focused on enhancing existing PMOs capability and value rather then creating new PMOs.

The second key finding was the increasing trend towards people seeing project management as a career. Over 70% of the people surveyed expected to stay in project and program management moving to larger projects or program manager/project director roles as their career develops. At the junior end of the spectrum, the emergence of PMOs provides an employment opportunity for project support staff to begin their working life as project admin staff, schedulers, etc., and then progress into project management.

The strategic importance of project management capability is also being increasingly recognised by senior management with a significant trend towards making project managers permanent staff roles rather than contract roles. The weak spot in this finding was that over 60% of organisations did not appear to have a project management career path defined to help develop their staff. Staff development will become increasingly important as 85% of organisation expect to increase their project spend this year and the job market is already starting to see shortages of appropriately qualified applicants.

The resources needed to develop a career framework are freely available, the PMI PathPro™ Career Framework can be used free of charge by any organisation to develop a customised framework and is also free to any PMI member to plan their own career development. Organisations that back the framework with effective training and mentoring to help employees grow their careers can offer a clear point of delineation in an increasingly competitive market for skilled employees. For more on PathPro™ and the various PM certification frameworks see: or download our report on the certification frameworks used in the Australian project management arena.

Software sales hype and the law

Effective and ethical stakeholder management is becoming mandatory. For decades the software industry has been able to largely ignore the needs of its clients, but the world is changing. The UK Construction and Technology Court is following the lead set in the BSkyB v EDS judgment and making software vendors live up to their promises! You can bet the rest of the world won’t be far behind….

In 2006 the Kingsway Hall Hotel paid £49,999 plus an annual licence fee of £7,528 for software vendor Red Sky’s Entirety package, which covered bookings, check-in and sales. Kingsway selected the system based on Red Sky’s recommendation.

Problems arose almost immediately. Issues included incorrect room availability and no-show reports, unallocated mini-bar charges and a main server crash. Entirety could not cope with group bookings and the servers frequently froze.

Kingsway’s solicitors wrote to Red Sky saying that Entirety was unfit for its purpose and Kingsway was entitled to reject it and seek damages. Kingsway claimed for loss of profit on lost room sales of between £222,000 and £311,000, plus £13,500 for an additional reservations manager, £36,333 for three additional shift leaders and £13,500 for wasted staff costs.

Red Sky claimed Kingsway had bought an off-the-shelf package after having ample opportunity to investigate it.

The judge held that Red Sky had been aware of Kingsway’s requirements and under section 14 of the UK Sale of Goods Act 1979 it could be implied that the Entirety software system would be fit for the purpose of increasing revenue and occupancy levels and allowing quicker check-in and check-out. Entirety did not meet that purpose, nor the standard a reasonable man would consider acceptable.

The court awarded Kingsway £50,000 in lost profits £24,000 in wasted expenditure and £38,000 for extra staff costs.

To avoid similar problems, effective requirements analysis is becoming mandatory backed up by delivering on the contracted promises to meet the identified stakeholder requiremets.


Kingsway Hall Hotel Ltd v Red Sky IT (Hounslow) Ltd [2010] EWHC 965 (TCC) – UK Technology and Construction Court May 2010

BSkyb Ltd & Anor v HP Enterprise Services UK Ltd & Anor (Rev 1) [2010] EWHC 86 (TCC)

IT Business Sued for US$300 million+

The IT industry is moving ever closer to mainstream contracting and vendors will be sued for non-delivery. Construction and engineering companies have been used to litigation over the non-delivery of contractual obligations for well over 100 years. Following the BSkyB v EDS judgement, the IT industry is now firmly in the same boat!

Earlier this year, the UK High Court handed down its decision in the long running case of BSkyB v EDS (now owned by HP) with the damages awarded against EDS likely to exceed £200m (US$300 million). The judgement will be appealed but stands as a warning for all IT vendors world-wide.

The dispute concerned the failed implementation by EDS of a new customer relationship management (CRM) system for use in BSkyB’s Scottish call centres. The project did not go well. After numerous key deadlines had been missed and various attempts to rectify the situation had failed (including re-planning delivery of the project by signing a ‘Letter of Agreement’ to supersede the primary contract), BSkyB severed its relationship with EDS in 2002 and completed the project in house (at a reported cost of £265m).

Litigation ensued, in which BSkyB made claims of, among other things, deceit (fraudulent misrepresentation), negligent misstatement and breach of contract by EDS. Despite EDS arguing that the project was derailed by the inherent risks in an IT project of this nature and BSkyB’s ‘vague and shifting requirements’, EDS was held liable for fraudulent misrepresentation, negligent misstatement, and breach of contract.

This decision highlights the fine line that must be trodden by service providers in promoting their offerings whilst pitching for jobs. Above all else, service providers should ensure that during tender processes they do not exaggerate their capabilities and should conduct thorough, documented assessments of prospective delivery timing before making any representations. Reliance on inherent risks in IT projects is unlikely, in itself, to be sufficient to substantiate any failure to meet representations “made by the sales guys”.

Welcome to the ‘real world’ guys…… See more on the judgement

Project Management 2.0

Project Management 2.0 (PM 2.0) seems to be going the same way some Agile anarchists are trying to take software development which is essentially not to do project management and hope a group of people with good will and good luck will create something useful.

Not doing ‘project management’ is a really good idea if you and your client have no idea what’s needed, when its required, or how much budget is available. Journeys of exploration can be fun and can be highly creative but are nothing to do with managing projects.

Wikipedia (retrieved 27/9/2009 from: lists the following differences between PM 2.0 and ‘traditional’ project management.

PM 2.0 -v- Tradtional PM

PM 2.0 -v- Traditional PM

Whoever wrote this has absolutely no idea what good traditional project management looks like and has probably never worked on a successful major project. Good traditional project management differs from this highly subjective and biased list in many ways:

  • Control is not centralised, authority and responsibility are devolved to the appropriate management levels.
  • All good project management is based on collaboration.
  • All good project management requires open access to the plan both as an input to its creation and to know what needs doing during delivery.
  • Access to information is vial when and where needed.
  • Open and effective communication is critical.
  • Project are,  by definition, separate management entities – a holistic approach (ie, not doing projects) is called general management.
  • Tools, see: A fool with a tool is still a fool, and you need the right tools for the right job. Amateurs try to do jobs with inappropriate tools. Easy to use and flexible are fine if you know exactly what you are doing, it is a recipe for wrong information and wrong decisions if you don’t.

The table is correct in so much as project management involves a degree of top down planning. Project management is about delivering a required output to the specifications requested by the client. The product or service is a failure if it does not meet the quality requirements set by the customer; which may include time, cost and scope parameters.

It is also correct in respect of the implied structure – projects work because there is an implied structure that sets a framework for collaboration. If you don’t know who is doing what it is nearly impossible to collaborate. Even Wikipedia and Linux have structure in their collaborative frameworks.

I have emphasised good project management throughout this post. Bad project management involves excessive attempts to ‘control the future’, lack of stakeholder involvement, excessive bureaucracy, and many other problems. These traits are bad management full stop.

One comment on the Wikipedia article is important though: PM 2.0 is good for small jobs. This is consistent with a survey of construction projects in the UK undertaken by the Chartered Institute of Building, focused on time management, which found that on ‘simple projects’ there was no difference in performance between those projects with a properly developed and managed schedule and those without. The same proportions finished early, on time and late.

However, as soon as the projects became ‘complex’; there was a marked difference in performance. Projects with effective schedule control performed significantly better than those without, and the bigger/more complex the project, the more significant the difference. ( I will put up a post on the CIOB’s work and its new practice standard for scheduling in a few days).

The CIOB’s findings and a closer look at many of the blogs and comments on both PM 2.0 and Agile seem to fit this trend. I would suggest two conclusions could be drawn:

  1. If the work is small, simple and easy to understand there is no need for much in the way of traditional project controls. Knowledgeable people know what needs to be done and can just get on with the work.
  2. If the required output is not capable of being determined by the client and the objective is to ‘create something wonderful’ it is very difficult to apply too many project management techniques – basically you don’t know what needs to be planned, costed and scheduled, etc. Time and cost are secondary to creativity and the exploration of problems.

In both of these circumstances traditional project management may not be appropriate. In fact I would question if either circumstance is actually a project given the definition of a project is to produce a defined product, service or result that meets the needs of a customer.

The challenge for senior organisational management is recognising the threshold where PM 2.0 and ‘free form Agile’ cease to be appropriate and more traditional forms of project management are needed. Traditional project management does not mean ridged control, the type of project influences what’s needed (see: Projects aren’t projects – Typology) but appropriate systems do help optimize cost, time and quality to deliver client satisfaction.

This does not mean dumping the new ideas, rather melding them into an improved project management process. Agile software development fits in nicely to ‘rolling wave’ planning. Similarly some aspects of PM 2.0 can really help enhance team communication and collaboration. Used wisely, these ideas and technologies simply help improve the way projects work to deliver quality outputs to their clients. This change is really no different to the shift from faxes and carbon copy paper to emails. Good project management has always adapted to use improvements in processes and technology to improve the quality of service provided to the project’s clients. This next wave of improved technologies should be no different.

However, be wary of the zealots suggesting the ‘old ways’ don’t work and should be abandoned and use examples of really bad project management to prove their point. This is even more important if the zealots also advocate employing them to solve all of your problems for a fee. Management fads come and go – modern project management has been generally successful in achieving positive outcomes for well over 50 years now and continues to evolve and improve. For further comment see Glen’s post on: Herding Cats

Thoughts on Agile

Following on from a rather lengthy on-line discussion covering various aspects of the interface between the Agile software development methodologies and project management, we have developed a discussion paper that looks at how the two processes can be integrated.

The paper is a ‘work in progress’ aimed at business managers who are new to the concepts of Agile (ie, it is not intended as an Agile manual for IT professionals). Any comments will be appreciated.

The paper can be downloaded from:

Agitating Agile

I have been involved in a series of posts on both my SRMM Blog (see post) and the PMI Voices on Project Management blog (see post) that have stirred up sections of the agile software development community.

Despite the Agile Manifesto focusing on providing excellence to stakeholders, many Agilists seem intent on advocating their rather extreme view of agile including no documentation, little planning or architectural design and less control. The mantra is ‘give the software developers free reign and you will get better software’. Whilst this may be true (although I somehow doubt it in anything but the smallest and simplest projects) it ignores the needs of the project’s key stakeholders.

Most IT projects exist to enhance the capability of the organisation. Consequently the software development is only one part of an overall project to change the organisation, deliver new capabilities or similar. In these typical circumstances, the IT component needs to meet predetermined requirements; any change in the IT capability delivered requires changes in other parts of the project. In fact the best IT solution may turn out to be an unacceptable business solution.

Meeting the needs of the businesses key stakeholders demands discipline and communication not just within the ‘scrum’ or XP team but to the customer’s managers. This needs at the very least a minimum of documentation to prove the IT team and its immediate customers understand their scope of work and other constraints and know how they will achieve the outcomes needed to support the business. Adequate documentation and effective communication are essential.

This post is not suggesting a return to Waterfall or other heavily documented software development process (they don’t work very well anyway – refer the Standish reports) but rather for an appropriate level of documentation to meet the genuine needs of senior management stakeholders. Saying ‘trust me’ is not enough and is not good stakeholder management.

Identifying the key stakeholders, assessing their requirements and expectations and then managing these key relationships so the stakeholders realistic expectations can be realised definitely involves up-front planning and effort, needs tools and methodologies such as the Stakeholder Circle® and involves on-going monitoring and control but is, I would suggest, worth the effort. Your project is unlikely to be seen as successful if the stakeholders expectations are not realised!

In most aspects of life the long term enjoyment of real freedom required a significant measure of self discipline. The agile extremists may do well to consider this and focus on meeting the needs and expectations of all of the stakeholders involved in their work.

PRINCE3 remains PRINCE2®

The complete refresh of the PRINCE2® project methodology and credentials is over and the 2009 version has been released.

PRINCE2 is a project management framework which has wide acceptance in many government areas. The intellectual property of PRINCE2 belongs to the British Crown which has placed the methodology is in the public domain.

Projects in Controlled Environments explains the name and the operative word is ‘controlled’. The business remains in control of its projects and everything in the method can trace back to this fundamental principle. This means the methodology works well in environments where the same organisations is the client and the primary ‘performing organisation’ for the delivery of the project.

The 2009 refresh has:

  • Added 7 principles that were previously implied.
  • Changed 8 Components into 7 Themes (Configuration Management has become part of the Change Theme).
  • Reduced 8 Processes to 7. The former Planning process is dealt with as part of the Plans Theme. 
For more on PRINCE2 see:
  • Added a new chapter on tailoring PRINCE2 to the environment in an attempt to reduce criticisms of the amount of bureaucracy involved in the methodology.
  • A Benefits Review Plan is now created as part of Initiating a Project and updated at end of each stage. Benefits Reviews may occur at the end of stages as well as after closure and the concept of dis-benefits has been introduced. Interestingly, the Senior User is held to account for the realisation of benefits (ie, the customer).
  • The Risk Management chapter has been rewritten to align with other OGC Standards. Response types cover opportunities as well as threats and a Risk Management Strategy introduced.
  • A smaller book focused on the needs of project sponsors ‘Directing Successful Projects with PRINCE2’ has been released.

The structure of PRINCE2:

The 7 principles which are considered universal and self-validating must exist in every project run according to PRINCE2. They are:

  1. Continued business justification
  2. Learn from Experience
  3. Defined Roles and Responsibilities
  4. Manage by Stages
  5. Management by Exception
  6. Focus on products
  7. Tailor to suit the project environment.

The 7 processes are outlined in the diagram above. Underlying these processes are the themes presented in the methodology and these amount to best practice in a project environment. They answer questions about what, why, who, when, how, how much and provide clarity. The Themes are:

  1. Business Case
  2. Organization
  3. Quality
  4. Plans
  5. Risk
  6. Change
  7. Progress


The primary difference between PRINCE2 and the PMI/ PMBOK® Guide view of projects is the boundaries. PMI (and most likely the new ISO21500) see a project starting when it is initiated by the client and completing once the outputs defined in the project charter are delivered. This is quite likely correct from a project practitioner’s perspective.

PRINCE2 sees the project starting much earlier and continuing through to the realisation of value by the organisation. This is quite likely correct from the perspective of an organisation initiating and managing internal projects.

There is very little difference in terms of the processes used to run a project between PRINCE2 and the PMBOK. What is different is PRINCE2 is totally focused on managing internal projects with organisational managers having a direct say in the management of the overall process and it provides an effective methodology for this circumstance. The PMBOK® Guide is a pure PM standard and has a more generic set of processes that can be adapted to a much wider range of circumstances and used in any situation (eg, a traditional project where the client contracts the project delivery organisation).

Which is best?  What do you think??

We will continue to focus on the PMI range of credentials with our training mainly because of their wider application. PRINCE2 works well in the right circumstances. Whereas, the PMI range of standards seem to apply to most circumstances. But I suppose that is the key difference between a methodology and a generic standard.

Managing Agile Projects

The two earlier blogs in this series focused on what’s NOT project management.

Agile and Waterfall are two different software development methodologies (see: Agile is NOT Project Management)

Operational maintenance with stable teams dealing with new work and maintenance upgrades on an organization wide basis is not project management even if there are new features being added to the IT infrastructure. This type of work is traditional operational management even if scrum and other Agile techniques are being used (see: De-Projectising IT Maintenance)

Traditional IT project management has grown up around and closely aligned with the Waterfall software development methodology. As with most engineering projects the final product to be delivered is scoped, designed, built, tested and implemented – in that order. This is OK if the client knows what it needs precisely and the number of changes is relatively small. Waterfall falls down (pardon the pun) if the project is a quest to achieve an objective and everything changes routinely.

Agile seems to be an ideally suited methodology for developing the software but if the work is also a project how should the PMBOK® Guide processes be applied? This blog will outline some ideas at a high level, later blogs may dig into some areas more deeply.

The PMBOK® Guide 4th Edition (2008) has 8 knowledge areas:

Project Scope Management
Traditional project management expects scope management to define the output. In an Agile project the final outputs should be defined in terms of achieved capabilities, how the capability will be achieved will be discovered along the journey.

This makes ‘Verifying the Scope’ interesting. There needs to be clearly defined way to assess if the capability has been delivered. How do you measure a ‘user friendly interface’? It’s not impossible to do but how it’s done needs to be clearly defined.

Change control is also more challenging, as is configuration management.

Project Time Management
Ideally time should not be an issue if the objective is to achieve a required capability. In reality there are usually deadlines.

In an Agile project, scheduling and workflow become closely aligned. The key requirement is an overall system architecture that defines the sequence modules need to be built in to allow progressive testing and implementation of capability. The software architecture defines the build sequence that defines the schedule.

Scheduling is at a much higher level though. A ‘sprint’ is likely to be a single activity of 1 to 2 weeks duration. The sequencing of the ‘sprints’ and the number of sprints that can operate in parallel define the resource requirements and the project duration.

Project Cost Management
Agile projects have to be based on a cost reimbursable system. One tool designed to include a degree of competition with the ability to properly compensate the contractor for its work is southernSCOPE the methodology requires tenders to bid on a project at a $ per function point rate based on a project description and the estimated number of function points. At the end of the project the same independent person who prepared the initial estimate, re-counts the function points and the price is determined.

Project Quality Management
This is probably easier under Agile; quality is continually assessed by the involvement of the client and the iterative release of modules to production.

Project Human Resource Management
Basically remains unchanged but the skills of the people needed for an Agile project are likely to be different.

Project Communications Management
The level of trust needed to run a Agile project is much higher than a traditional project. Effective ‘real’ communications in all directions are essential. This is different to producing project reports! More later.

Project Risk Management
Recognize you are on a journey focused on delivering value. Significant time and cost contingencies are needed and should be used to optimize the value of the final product. More later!!

Project Procurement Management
This should not change significantly BUT the procurement process needs to be aligned to what it is buying. Agile works in a collaborative partnering space. In the engineering world these are call Alliance Contracts. Traditional contracts will not support Agile delivery methods.

In conclusion: align the PMBOK to an Agile project delivery method and the overarching PM process will enhance the probability of success. Treat an Agile project in the same way as a traditional Waterfall project and the PM processes will guarantee failure!