Category Archives: IT Project Management

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: http://www.companydirectors.com.au/ags

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: http://www.gartner.com/newsroom/id/2819918

The Gartner IT Hype Cycle.
See: http://www.gartner.com/newsroom/id/2819918

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: http://www.pgcs.org.au/.

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: http://www.mosaicprojects.com.au/Training-PMI_Framework.html 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.

References:

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: http://en.wikipedia.org/wiki/Project_management_2.0) 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: http://www.mosaicprojects.com.au/PDF_Papers/P109_Thoughts_on_Agile.pdf

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.