Project Assurance

Project Assurance is a discipline that seeks to provide stakeholders with objective oversight of the likely future performance of major projects.

Organisations are under enormous pressure to deliver products and services at a faster pace of change than ever before. Governments at all levels face immense pressure to deliver public services faster and cheaper and this is increasing.

Having a rigorous approach to identifying the right projects to invest in and delivering them successfully will ensure maximum return on investment.

IBRS can help you and your organisation maximise the outcomes from project investment and increase project success. From well-prepared business cases, support through all stages of the procurement phases, effective delivery of project activities through to realising the expected benefits from project investments.

Conclusion: CIOs today are often faced with deciding whether to buy integrated systems solutions and services from major vendors or buy best of breed solutions from multiple vendors and manage the integration project in-house.

Organisations that have engaged external services providers on a major scale and eroded their IT skills base typically find they have no option but to buy the integrated solution. Conversely those with specialist skills in-house and the need to develop their people, often find in-house systems integration solutions more attractive.

Read more ...

Conclusion: It is easy to sheet home the blame for IT project cost overruns to difficulties experienced in estimating work days required. Whilst estimating is difficult it can be converted from an art form into science by identifying the tasks required in detail and estimating the work days required for each one. Include the total in the business case.

Read more ...

 

Conclusion: They usually begin with starry-eyed stakeholders. Too often they end in tears. After several years of fiscal restraint, blockbuster projects are back on the agenda. Many will fail. Others will fall well short of organisational expectations.

Read more ...

Conclusion: The prototyping of user interfaces is moving beyond traditional low-fidelity static wireframes and embracing more sophisticated approaches to simulate the entire application experience. Modern solution visualisation tools can deliver a more accurate and dynamic rendition of complex enterprise applications before a line of code is cut. This can significantly reduce delivery risk and improve development productivity. Beware though the diminishing returns from overly complex solution visualisation tools that absorb the cost and risk that they should be offsetting.

Observations: Prototyping has long been a means to visualise early in the system development lifecycle how a system should look and behave. This has the benefit of allowing a system design to be validated as early as possible by subject matter experts. While textual based requirements remain the primary contractual specification for system development, they are often hard to fully comprehend without the kinesthetic aid of a visual prototype.

A good prototype should put abstract and generalised requirements into the context of real life business processes and user interactions, creating a rich dialogue between system designers and users around the system’s expected behaviour. The use of a prototype to assist in the harvesting of correct, concise and consistent requirements can pay off considerably in the long term. Studies show that addressing defects in the requirements phase can be 100 times cheaper than fixing them as post-implementation defects.

Traditional prototyping: Low tech prototyping tools such as butchers paper, white board markers and post-it notes can be immensely valuable design tools when combined with adept user interaction facilitators and knowledgeable subject matter experts. Rapid storyboarding of anticipated system behaviour from a variety of stakeholder perspectives can generate a robust high-level shared view of system functionality. This can help establish, or challenge, the important assumptions and principles that will guide detailed design work.

The use of productivity applications to generate basic user interface mockups (Powerpoint, Visio, OmniGraffle) or RAD development tools (such as Dreamweaver and Visual Studio) to create HTML or native-app click-models have become common prototyping tools. In the case of RAD development tools the lurking danger is that users or (even more worryingly) executives, begin to see the prototype as almost the finished system. This can lead to pressure to “put the prototype into production” without the required underlying architectural support, or set false expectations about the considerable extra effort required to implement complex integration and business rule support. To avoid this situation a common rule is to implement a “throw away” prototype using a technology that is impossible to deploy into production.

Solution visualisation: New prototyping tools (such as iRise, Axure and SketchFlow) have emerged that support the end-to-end simulation of applications without the overhead of custom development. These “solution visualisation” tools enable the definition of rich visual user interfaces with advanced interactive features such as data entry, simulated business rules and complex navigation logic. Supporting these design elements are collaborative features that enable applications to be reviewed, annotated and critically evaluated in a fashion similar to the “mark-up” features of modern word processors. These prototype applications can often be packaged for easy distribution by email, facilitating analysis and review without the overhead of maintaining access to prototype infrastructure.

While solution visualisation tools can quickly deliver rich prototypes that flesh out high-fidelity representations of desired systems, the cost of purchasing such software and the effort to maintain complex prototype models can undermine the core benefits of prototyping. The benefit of common tools such as HTML editors or office productivity application lies in their ubiquitous availability and universal accessibility. Complex solution visualisation tools may require expensive up front license costs and/or proprietary file formats that require specific reader software to be installed for the viewing of applications. They may also require centralised repositories to be installed into server environments. These tradeoffs need to be carefully considered before embracing a solution visualisation toolset.

Multiple device simulation. The enterprise application landscape is changing. Touch phones and tablets have established a need for mobile “finger-driven” apps as much as there is a need for “mouse-driven” desktop apps. Corporate applications are demanding dual-mode solutions that support finger operated Android and iOS access just as they do web-based or rich native applications. This need is adding an extra burden on prototyping efforts to support multiple target platforms. Solution visualisation tools can help manage consistent requirements across a multitude of platforms.

ALM tool integration. The key outcome of solution visualisation or prototyping efforts is a consistent and complete set of requirements. In the modern software world applications are often managed by dedicated tools or as part of application lifecycle management (ALM) suites. Effective solution visualisation tools need to be able to integrate into the requirements and design management tools that support the end-to-end development lifecycle. This allows solution visualisation tools to be institutionalised in the core process of application delivery, rather than sidelined as a niche user experience activity.

Next steps:

  1. Organisations should carefully evaluate the use of prototyping in supporting custom application development. Is it effectively contributing to the quality of application design before moving into the development phase?

  2. If basic prototyping tools are not being used effectively start with the low fidelity approach and embed their use into upstream requirements and design activities.

  3. If basic prototyping has reached a ceiling of either design richness or stakeholder reach, consider solution visualisation toolsets. Consider carefully the Total Cost of Ownership of such tools against the anticipated benefits.

McConnell, Steve (2004). Code Complete (2nd ed.). Microsoft Press. ISBN 0-7356-1967-0.

 

Conclusion: Establishing, or re-launching, a Program Management Office (PMO) using a text-book driven, ‘cookie cutter’ approach is not likely to bring about improvements in the performance of individual projects, IT programs or even a portfolio of projects. While some initial improvements may be observed as a consequence of closer management scrutiny, it is rare for formula-based approaches to work effectively on a sustained basis.

Read more ...

Conclusion: Technical debt is a metaphor for the ongoing cost of bad IT decisions. As with debt in the real world, interest is paid on technical debt in the form of increased cost of operations and maintenance, poor quality solutions and loss of enterprise agility. Prudently managed technical debt can be a useful tactical tool, however uncontrolled technical debt can rapidly become an overwhelming burden and severely reduce the ability to invest in new initiatives. This is toxic technical debt. Crucial to managing technical debt is having an approach to identify and track when and where it is incurred.

Read more ...

Conclusion: IT Strategic Plans typically include a long term application pathway for offering enhanced services to clients, and better management information. In reality this is just the beginning of the journey from concept to benefits realisation. To succeed, project sponsors need to take the initiative and gather arguments that will ensure funds are allocated to their projects by the governance group as soon practicable.

To minimise management tension the governance group has to create a level playing field and equitably allocate resources to sponsors whose projects best contribute to meeting business objectives.

Read more ...

Conclusion: During the GFC many organisations lost their innovation mojo. As economic rationalism reigned, organisational cultures became stale, research and development budgets were cut and fresh ideas stopped flowing.

Read more ...

Conclusion: Recent Standish Group research1 has shown that project failure rates for IT-based projects have risen since from 19% in 2006 to 24% in 2009. Running projects successfully has become more challenging in recent times as the lingering effects of the GFC tempt project participants to cut corners. Strengthening methodology observance and project governance arrangements may result in some improvements in success rates. However, IBRS believes that greater benefit can be achieved by transcending such mechanistic approaches. We advise a holistic re-examination of candidate projects using our 6C2 approach, then re-configuring those projects where necessary to improve their chances of success.

Read more ...

Conclusion: Organisations aiming to improve the effectiveness of their EGIT (Enterprise Governance of IT) initiatives must ensure they apply best practices in relationship management with all stakeholders. This is because effective governance is dependent not only on having the right framework in place, but also people skilled in stakeholder relationship management positions to implement them.

Read more ...

Conclusion: Failed projects are newsworthy again. The most recent report from the Standish Group, which has studied over 70,000 IT-based projects since 1985, indicates that project failure levels reached new heights during the GFC. Prima facie, this is counterintuitive. Additional controls (such as closer scrutiny and reduced tolerance levels on spending) and cautionary approaches have typified executive responses to the GFC. However, cost-cutting to meet agreed targets and attempting to hasten project delivery in an already resource-lean environment will have contributed to this result.

Read more ...

Conclusion:The need for an overarching framework to drive business value from IT through value management processes, supported by mature delivery service processes has prompted the need for an enterprise-wide approach to IT governance1

Read more ...

Conclusion: Enterprise governance of IT (EGIT), the objective of which is to drive business value from IT, is a new concept. It also goes beyond traditional IT governance, which focuses on effective delivery of services, by seeking to transform IT so it can meet the current and future demands of all clients.

CIOs who can drive the transformation of IT and help drive business value through their leadership role with the senior management team will always find their services in demand.1Conversely those who do not take up the dual challenges run the risk of being perceived as operational managers only, and potentially limit their career advancement options.

Read more ...

Conclusion:An often reported issue with our clients is that they find the process of benchmarking costly and time consuming, while rarely does it provide them with worthwhile information. After discussions with those involved we have found that this dissatisfaction is often due to a small number of issues which could have been resolved prior to undertaking the benchmarking process.

Read more ...

Over the last 2 years I’ve been surprised to find a number of e-mail and file archive projects that had failed very badly. I say surprised because for most of my career I’ve worked on infrastructure implementations, and while they are complex and messy, they generally workout Ok in the end.

After a few discussions with clients it dawned on me that while archiving is generally being implemented as an infrastructure, usually by IT infrastructure staff, it is very, very different from a typical infrastructure project. In particular archiving sits somewhere between a traditional infrastructure, i.e., some hardware and software that is generally very stable and has limited end-user features, and business applications, i.e., large scale software projects with extensive end-user features.

Read more ...

Conclusion:Knowledge workers – and people in general – commonly overestimate their ability to convey information in documents, diagrams, and in discussions. To make matters worse, they typically have too much faith in the validity of their personal mental models to frame the problems that need to be solved. As a result, misinterpretations often remain undetected for months, milestones are missed, and deliverables don’t meet expectations. There is no antidote against project failure in terms of a universally applicable methodology, but many failures are avoidable by recognising that communication and collaboration is fraught with difficulties.

Read more ...

Conclusion:It is tempting to seek out easy solutions for hard problems. Many others must have had similar problems, and a large part of the solution development effort can be short-circuited by selecting an appropriate productised solution – that’s hope. But similarities between problems in different organisations are easily over-estimated – that’s uncertainty. Business cases are strengthened by highlighting key differences to other organisations, and by proposing a path that incrementally removes uncertainty.

Read more ...

Compiling and publishing IT policies and procedures (ITPP) is an important part of IT governance in order to ensure proper use of the computer network and security of vital data. But however detailed and well-designed these ITPP are their publication in itself is only the start. Ensuring that they are understood, accepted and adhered to is an on-going challenge which must not be underestimated.

Read more ...

Conclusion: When establishing or enhancing an IT governance framework, one size does not fit all. For full effect, governance practices need to reflect an organisation’s ethos. Time can be the enemy of good governance practice; what works well at the outset may need to be tailored and progressively refined to suit evolving organisational maturity, changes in personnel and the interest of executives in contributing to the IT agenda. In essence, a multi-factorial, time-phased approach is recommended for instilling and maintaining effective IT governance.

Read more ...

Conclusion: Astute CIOs know that to be successful they must assume, or act out, many roles. One role they must not overlook is that of engaging stakeholders during the budget or planning cycle and helping them identify ways to maximise the benefits of existing IT investment and canvass ways to exploit emerging technologies.

Read more ...

Conclusion: Organisations with immature IT governance processes push many of the decisions that need to be made by the business, back to IT. This creates a downward spiral, often characterised by IT making poor decisions about business/IT investments (due to insufficient business context), consequential failure by IT to deliver business value, then loss of confidence in the IT function, sometimes resulting in the CIO losing his or her job.

Read more ...

Conclusion: The terms “IT” and “governance” are frequently coupled, sometimes glibly and often inappropriately. Indeed, IT governance seems to have a multiplicity of meanings but is generally seen by IT people as a “white knight” in which business user engagement, properly executed, will overcome a troubled IT situation.

Read more ...

Conclusion: Project managers often find management of the change process one of the hardest aspects to deal with in their projects. While they have been trained to deal with facts and figures using templates and other project management aids, rarely do they have the necessary skills and experience to successfully manage the workplace change associated with their projects.

Read more ...

 

Project managers often find management of the change process one of the hardest aspects to deal with in their projects. While they have been trained to deal with facts and figures using templates and other project management aids, rarely do they have the necessary skills and experience to successfully manage the workplace change associated with their projects.

Read more ...

Conclusion: As discussed in “Backup is not Archive!1 all IT organisations should evaluate deployment of an archival platform. However, based on numerous client conversations and a recent survey, it is clear there are significant project risks in implementing archiving. One-quarter of archiving projects take more than two years to implement and nearly half of IT managers state that they would not recommend the archiving product they had selected!

Read more ...

Conclusion: Australian taxpayers should applaud the Rudd government for adopting in full, all the recommendations of the Gershon Report.1 As a consequence, IT savings of an estimated $1 billion are planned for realisation over the next 10 years. However, will the government be able to bank all these savings? The answer is probably no. Intentionally or otherwise, what Gershon proposes is nothing more or less than a wide-scale, transformational change program. These unfortunately, rarely meet with complete success2.

Read more ...

Conclusion: Despite considerable advances in the discipline of project management many organisations continue to report unacceptably high rates of failure for their IT projects. There are, however, a number of initiatives that organisations can take, particularly in the planning phase of IT projects, which can significantly reduce the likelihood of project failure.

Read more ...

Conclusion:The recession has brought the prophets of gloom out in force, all predicting massive cuts in the IT budget, with many of them also telling us how to address this. Their solutions are often facile and naïve, most boiling down to “do this to be more efficient”, ignoring the fact that most good IT shops have already made themselves highly cost-effective and have little room to move to reduce costs. Other commentators have recognised this and are predicting that the major savings in many IT shops will be by stopping or deferring projects.

Most IT shops have a range of projects on the go at any time, all with committed teams and management support. Determining which projects should be stopped or deferred may require the judgement of Solomon, and like Solomon, the IT manager should not be the one to make the decision. The projects are all, presumably, business focussed and the business should make the decisions.

Read more ...

Conclusion: The ability of organisations to implement major strategic business initiatives is to a large degree dependent on their ability to successfully execute the program of projects on which these strategies are reliant. Despite the importance of such programs most organisations, while accustomed to the demands of managing individual projects, often lack the skills and experience required to manage the complexity of such programs. The recruitment of an experienced program manager to lead the program and an integrated approach to program governance and planning can go a long way to ensuring a successful outcome.

Read more ...

Conclusion: Standards Australia has developed and published the Australian Information and Communication Technology (ICT) Governance Standard1, the first government driven ICT Governance Standard in the world. This provides an opportunity for ICT dependent organisations to revisit their ICT governance and confirm it meets agreed good practice. It is also a useful template for any organisation that is setting up or re-examining its ICT governance, policies, and procedures. It should be used by company directors, owners of small businesses, and other organisations to recognise and accept their ICT responsibilities and to set in place processes that ensure that ICT meets these obligations.

Read more ...

Conclusion: Stakeholder management is a critical, but often overlooked aspect of project management. Insufficient attention to the needs and attitudes of project stakeholders can lead to project failure even when the more well known components of project management have been addressed.

Read more ...

As countries struggle to improve their populations’ dietary habits, now may be the right time to borrow an idea from the ICT industry: just claim it, whatever it might be, leads to higher productivity. The argument seems to work because products that linger on shelves start to move with this simple but effective message. It also motivates policymakers to design grand projects on the basis of productivity gains; it is at the centre of how business is done and it provides an unassailable argument. No one would deny the benefits of productivity.

Read more ...

Where a major information technology project is discontinued; failure to provide this will result in a significant project financial loss, diminished credibility for the IT Department and, for mission critical projects, could mean a loss of revenue for the organisation.

Read more ...

Conclusion: Unless an organisation consistently conducts project PIRs (Post Implementation Reviews) for business systems (IS development, staff training and business process redesign) and IT Infrastructure projects it cannot claim to be learning organisation.

Done well the reviews can help avoid mistakes of the past, sustain the project’s benefits and aid staff development.

Organisations that do not review outcomes from business systems and IT Infrastructure projects, or do review them but pay little attention to the lessons learned, will probably continue to make unwise business systems investment decisions and fail to develop their people. 

Read more ...

Conclusion: In March 2001 the Organisation for Economic Cooperation and Development (OECD) published a management brief1 addressing problems in implementing large IT projects in the public and private sectors. Observations in this report included “...budgets are exceeded, deadlines are over-run and often the quality of the new system is far below the standard agreed when the project was undertaken”.

Read more ...

Conclusion: Many organisations continue to have trouble having projects complete within budget, on time, and meeting user requirements. This is in spite of a plethora of project monitoring metrics and methodologies designed to prevent this happening.

Read more ...

Conclusion: Project Portfolio Management (PPM) is now viewed as a necessary pre-condition for maximising the contribution of an organisation’s IT projects to the achievement of corporate goals. Unfortunately many Small to Medium Size Enterprises (SMEs) have made the decision not to implement the process due to its cost. The guidelines provided in this paper have been found to be effective in allowing a scaled down version of PPM to be implemented in a cost effective fashion within SMEs.

Read more ...

With increasing use of external service providers CIOs and IT managers find themselves having to prepare an increasing number of RFPs (Requests for Proposals) to select the right provider at the right price.

Read more ...

Conclusion: A frequently reported cause of IT project failure is a lack of senior management ownership and leadership.1 This often first manifests itself in problems in the deliberations of the project’s steering committee. Measures that can reduce the likelihood of such problems occurring include the selection of committee members who meet the criteria given in this paper and the use of a Kick Off session to gain agreement on roles and expectations of both the committee members and the project manager.

Read more ...

Conclusion: One widely used mechanism for identifying project issues and assessing the overall status of projects is the concept of the project Health Check. The concept of an independent review, generally of high risk projects, has proven useful in providing guidance to management as to where corrective action needs to be applied in order to improve the prospects of project success. 

Read more ...