Novopay has become a huge cost (some $1.5 billion) for us hapless taxpayers, and for schools in terms of the stress it is causing staff and the time schools have to spend attempting to fix the problems. As at posting this blog item, principals say Novopay is still struggling to pay their teachers properly, with an average of almost six teachers at every school affected by incorrect payments. Novopay complexity was completely under-rated and the ‘big bang’ launch proved disastrous. Novopay like INCIS before it will be a case study on IT courses for years to come. Hopefully the upcoming IRD project is more successful and perhaps Kiwi companies should get a chance to do this job?
It is surprising if not alarming that significant numbers of complex software and IT projects around the world still fail to deliver their key benefits on time and to target cost and specification. These problems are no doubt fuelled in large part by the exponential growth in the capability of hardware and communications technology, and the corresponding inflation in people’s expectations and ambitions.
Risk management is critical for success in these complex projects but seldom seems to be applied effectively in the case of IT and software endeavours. Although major projects in other disciplines also have to contend with complexity, it seems that in software engineering, complexity is harder to understand, detect and manage. There is a large discrepancy between best practice and common practice in IT and software projects.
We might classify projects as simple, complicated, complex or chaotic. This blog item considers complex projects. We recognise that risk has a positive correlation to complexity. Complex projects are in most cases more risky.
Complexity seems to be used to characterise something with many parts in intricate arrangement. However, the use of the word is causing debate amongst project management practitioners. Is my project complex? Yet, have we ever managed a project that was not complex? Every project manager I know considers that they manage complex projects. And since the opposite of complex is simple, would we need a project manager for a simple project? The Association of Project Managers (APM) refer to complex and non-complex projects, but what does a non-complex project look like and what do the APM mean by a complex project?
What seems to be important is to identify the source of a project’s complexity, the level and also the implications of this complexity. Several academics have studied the different dimensions and established different classifications of complexity. These have been put together into models of complexity. Personally, if we can’t explain our project to a 12 year old in about 5 minutes such that they understand it, we most likely have a complex project. Nevertheless, in the last three decades, complexity theory has gained a lot of importance in several scientific disciplines like astronomy, geology and chemistry. It has now extending into the field of project management where developing a software application is doubtlessly a complex process with a large number of variables that can have a major impact on the final product.
Check here for a Project Management Institute’s publication about managing project complexity. The PMBOK’s definition of complexity seems to be a bit limited and may confuse complication with complexity. Complicated projects are relatively common and are delivered by decomposing the projects into less complicated chunks. However, a complex project has many varied and inter-related parts, and from a risk management perspective, complex projects do need special management due to their high level of uncertainty. This uncertainty means that it’s not easily predictable how a change in one thing might affect other things in the project. As a consequence there may be many “unknown-unknowns” – those “black swan” risk events as they’re sometimes called.
So complex projects aren’t necessarily bigger. A project can be large and simple. Project complexity has at least two key dimensions:
Business complexity. Each project is driven by its own level of business complexity, such as competitors, cross-functional interactions, current business processes, customer buy-in, financial exposure, geography, regulatory restrictions and so on. Each such attribute could be assessed on a complexity continuum, from low to high.
Technical complexity. Every IT project is driven by its own attributes of technical complexity, such as security needs, stability of hardware, and software, transaction volume, project team experience, and level of technology integration, among others.
Some specific sources of project complexity are these:
- Many stakeholders with different agendas.
- Many different deliverables.
- Dependence of one deliverable on others.
- No prior experience with this type of project.
- Unsuitable contract for the project type.
- Operational and business-as-usual pressures.
- Resourcing problems.
- Little or no proactive planning – an absence of forward thinking.
- Too much interference from the client and other key stakeholders.
- Changes in government policies and legislation.
- Inadequate communication among all involved.
- Cultural differences.
- Unsatisfactory leadership.
- Poor decision making and problem solving.
- Office politics.
- No clear definition of the project goal and work scope.
- Unsatisfactory project team member attitudes and aptitudes.
As part of the tender process, suppliers should convincingly demonstrate they have the technical, leadership and managerial skills required to deliver a complex project. Some other things to keep in mind are:
Project goal, objectives and success criteria. If we can’t clearly describe the project goal, objectives and success criteria then project complexity increases because of the difficulty progressing towards satisfactory deliverables, outcomes and benefits. For example, a project to reduce cost by the introduction of a new automated system cannot be clearly specified until existing processes have been understood and the précis changes required have been identified.
Stakeholders. Diversity of views among stakeholders and interested parties may create complexity in agreeing the project goal and objectives, and execution method. Conflict between key stakeholders can significantly increase the challenge. Typically this can be conflict between the different parties within the customer and the supplier organisations over the desired project outcome or implementation process. Such conflict can make it extremely difficult for the project manager to clearly understand and meet the customer’s requirements. This is especially true if powerful and influential stakeholders are involved in the project.
Cultural context. Cultural or social context can significantly increase complexity not only in multi-national projects but also in those that have to adapt to diverse cultures within multiple organisations and stakeholder groups. This introduces not only logistical difficulties associated with time zones but also misunderstanding about the intentions and working practices of the different parties.
Innovation. If the solution required is unknown at the outset then resolving technical issues as the project progresses will significantly increase project complexity. The same is true for any non-technical innovations such as novel financial, legal or organisational structures; these too tend to increase complexity.
Co-ordination. Co-ordination problems are largely a function of the number of parties and different approaches to project management within the delivery organisation. The difficulty co-ordinating these parties can result in increased complexity and the number of communications channels and vested interests.
Project Organisation. The number of and diversity of delivery organisations can increase the level of project complexity. This is especially when organisations, which make up the project team have divergent values, cultures, behaviours and objectives – sometimes covert motivations.
Leadership. Changing project team and leadership and one that is unable to make timely decisions can ratchet up complexity, as key decisions are deferred. Conflicts or frequent changes in project leadership can also introduce complexity to the project as the team attempts to adapt to the changing leadership styles.
Constraints. Resources and the constraints associated with their availability and restrictions on their use can increase complexity. These resource constraints can be physical (access to the work location), geographical and human.
Risk. The inability to predict or foresee risk, leads to a more complex project because the plans and contingencies required to manage the risks cannot be established in advance.
A characteristic of many, although not all failed IT projects seems to be that they were ill-conceived and over-ambitious. Their risks were not perceived at the outset and hence not properly managed. It is therefore vital that the risks are properly understood at an early stage so that appropriate risk management measures can be taken – which, in the extreme, may mean not embarking on the project.
Thus, before proceeding with a major IT project, we might ask ourselves questions such as:
- Why are we doing this?
- What contribution will this make?
- Is the project sponsor prepared to devote enough time to properly understanding this project and monitoring its progress?
- Are expectations for this project, including time-scale and budget, realistic?
- How important is it that we do this, given that it will cost a huge amount of money, time and disruption?
- Can we sustain this project with all the other things that are going on as well?
- Do we have people with the right skills and knowledge, who we can trust to handle this project?
- Have we done something like this before?
- Do we fully understand the risks involved with this project?
- What can we do to manage those risks?
- How would this project be affected if the market changed, the government changed, or a new technology became available?
- Do we have a recovery plan if things go wrong?
If we do not feel qualified to answer these questions, perhaps we need to seek expert help. If necessary, employ an independent review team to assist in addressing our concerns and monitoring progress. We must clearly define the business benefit that will be delivered by the project – this must be absolutely comprehensible and defensible. If different key staff give different answers, we have cause for concern. Also ensure that we know how delivery of the business benefit will ultimately be assessed, and who will take responsibility for this process.
A general rule is ‘keep it simple stupid’. This means avoiding ‘big bang’ project implementations unless essential, and being willing to use off-the-shelf packages where possible, adapting our business and management processes to fit the system rather than tailoring the system to suit our organisation. Although this may seem an unattractive compromise, the chances of achieving a successful outcome are likely to be improved.
Finally, throughout the course of the project, ask our project team and other stakeholders what worries them most about the project and what could go wrong. Their answers are likely to be much more informative than if we ask them whether everything is on track. Establish readily accessible risk and issues logs for this purpose. In fact, from a risk management perspective we shouldn’t take on a project whose complexity outstrips team capabilities unless it is a prototype perhaps and the only goal is to learn from it.