Software & IT projects

Location:  PMKI > IT & Construction Industries > Software & IT projects. 
The PMKI Library

PMKI Index
the PMKI

This subject looks at the aspects of project controls and management specific to the ICT industries.

Topics included in Software & IT project Management:

- IT Project Management Overview
- Agile Approaches to Development 
   -  Agile Overview
   -  Estimating for Agile
   -  Controlling and Governing Agile
   -  Calculating status and completion 
   -  Administering Agile Contracts
   -  Agile resources
- Traditional Approaches to Software Development
    - Waterfall
- Useful External Web-links & Resources.

Other related sections of the PMKI:

- Product Development 
- Project management software


Software & IT Project Management Overview

IT PMArt: The Insidious Effect of Technical Debt - The concept of technical debt refers to the costs of having to go back and resolve problems that arise because an earlier decision was made to take an easy option, instead of the best one.

PP: The Paradox of Project Control in a Matrix Organisation. This paper explores the hypothesis that, within complex matrix organizations, the ‘zone’ between the strategic vision set by senior management and the projects created to fulfil it, is a highly complex and dynamic organism that's reaction to stimuli cannot be predicted. Succeeding in this environment needs a different management paradigm from that developed for management in traditional project industries. The characteristics of a complex matrix organization include: multiple/competing lines of authority, virtual and partial/part time teams, divergent objectives, and many competing levels and types of authority. This paper describes the paradigm shift in management thinking needed to succeed in managing projects across this ‘zone’. To succeed, managers need to combine vigilance and agility to identify and capitalize on unexpected gains and deal with unexpected problems.

Note: A comprehensive list of software suitable for managing ICT projects can be found at
Project Team Management & Collaboration software.



Agile Approaches to Development

AgilityAgile is a general term, derived from the Manifesto for Agile Software Development which states:

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.

This statement is supported by twelve principles that define a way of developing software and other ‘soft products’ focused on flexibility and adapting to changing user or customer requirements to maximize value. The agile approach (or philosophy) is, with a few word changes, applicable to most projects most of the time. Whereas the specific methodologies created for software project management such as Scrum have a significantly more limited sphere of application. 

We are not experts in any of the various and evolving agile methodologies, the most prominent seem to be Scrum as the method of working, with Disciplined Agile (DA) and SAFe® (Scaled Agile Framework) as the overall management approach, where DA can be used to create context-sensitive options that optimize SAFe practices and ensure the delivery of business solutions. The papers in this section are written from a business and governance perspective, not a technical agile perspective, for up to date technical resources see the 'agile resource links' below.

The history of developing software using agile concepts predates the Agile Manifesto by many years, this is discussed in A Brief History of Agile, part of our History of Agile, Lean, and Allied Concepts page.

This topic looks at the practical application of Agile in a business environment. Click through to see more on Product Development & Maintenance


Agile Overview

DP: Thoughts on Agile.  Agile is a way of developing software and other ‘soft products’ focused on flexibility and adapting to changing user or customer requirements to maximize value. This paper looks at the implication of managing an agile approach to product development.

Art: There’s Agile and there’s Agile, understand the difference!  This article defines three very different business environments where 'Agile' approaches can deliver real benefits and identifies the differences in management approach needed to maximize value for the organization.

Art: De-Projectizing IT Maintenance. Not everything in IT needs to be a project – by de-projectizing maintenance work major improvements in delivery are possible.

Art: Processes -v- People. You can get the best of both worlds by embedding organizational agility into your procedures, methodologies and management.

Blg: What is Agile? The Agile Manifesto sets out a philosophy not a methodology and change the term ‘software’ used in the manifesto to product (or output), it is a generally applicable philosophy.

Blg: What is Agile? The


Estimating for Agile 

Planning poker, also called Scrum poker, is a consensus-based, gamified technique for estimating, mostly used to estimate effort or relative size of development goals in software development. In planning poker, members of the group make estimates by playing numbered cards face-down to the table, instead of speaking them aloud. The cards are revealed, and the estimates are then discussed. By hiding the figures in this way, the group can avoid the cognitive bias of anchoring, where the first number spoken aloud sets a precedent for subsequent estimates.

Click through for a list of estimating tools.


Controlling and Governing Agile

Prs: Controlling Agile. A review of the decisions, questions and options for effectively integrating project controls with an 'agile' product delivery methodology.

Prs: Governing Agile – the changing role of project controls in an ‘agile’ environment. The challenges of governing and managing an 'agile' environment are significant. This presentation suggests an appropriate framework for the overall governance of agile projects (including the role of a steering committee) and outline the controls framework needed to support both the management and the governance of the project.

Art: How should the different types of project management be described ?. This article looks at the challenges of categorizing projects based on the 2024 PMI classification process of Predictive - Hybrid - Agile and the consequential consigning of waterfall to history.The key finding is getting the right balance between Agile and Predictive drives project success.

For more on the challenges of scheduling and controlling Agile projects see: Schedule control in Agile and Distributed projects.


Calculating status and completion

WPMThe core elements of an agile approach are the project team and stakeholders develop a backlog of work to be done to achieve the desired objective, and then at regular intervals the project team selects the next items to do from the backlog. The underlying assumption is a committed and skilled team actively involved in the work are the best people to decide what should be done next, and the best way to do it. However this agility introduces a range of controls challenges, in particular assessing the current status from a time perspective, and calculating an expected completion date.

PP: Calculating Completion. Tools used for assessing status, and predicting the completion of projects include: Bar Charts, Burndown Charts, Kanban Boards, Velocity, CPM, EVM + ES, and Work Performance Management (WPM). This paper considers each of these options against a highly simplified project, with a focus on the subjective and objective information available from each tool and how they compare.

Art: WPM for Agile Projects. This article identifies the cause of the gap in Agile project management, the inability of current tools to accurately predict completion and demonstrates how WPM will effectively close this gap. Most project sponsors and clients need to know when the project they are funding will finish, other people are dependent on the project's outputs to achieve their objectives. WPM provides this answer based on consistent, repeatable, and defensible calculations.

WPM works within than Agile paradigm to assess progress and predict completion based on comparing the work achieved to the work planned to be achieved up to a point in time.
See more on Work Performance Management (WPM).


Administering Agile Contracts

The law of contracts requires the project to comply with the agreed contract obligations and for it to be administered in accordance with the terms of contract. The penalties for failing to comply with the terms of the contract can be severe. Using a agile methodology to accomplish the work does not change this fundamental set of legal requirements! The contract may be adapted to facilitate the use of agile, but ultimately the terms of the contract set out the agreement between the parties.

Blg: Commercializing Agile. Choosing to use Agile as a project delivery methodology will not change the laws of contract, which means organizations using the agile methodology will need to become more commercial and adapt their processes. This post looks at some of the issues involved in administering contract claims when agile methodologies are being used to deliver the project output.

PP: Assessing Delays in Agile & Distributed Projects. This paper focuses on assessing delay and disruption in projects where there is no CPM schedule, other agile or adaptive approaches are being used to manage some or all of the work. This paper offers a practical solution to the challenge of assessing delay and disruption in this type of agile and distributed project, where the traditional concept of a ‘critical path’ simply does not exist and the effect of intervening events has to be considered in terms of loss of resource efficiency.
Download the PowerPoint: P215 Assessing Delays In Agile & Distributed Projects PPT 
Click through to see more on assessing delay and disruption.

Blg: Software sales hype and the law. This post looks at the problem of over promising and under performing in software delivery.  The software has to be fit for its intended purpose or the vendor is likely to be held liable for the clients losses.

Blg: IT Business Sued for US$300 million+. Construction and engineering companies have been used to litigation over the non-delivery of contractual obligations for well over 100 years. Following the 2010, BSkyB v EDS judgement, the IT industry is now firmly in the same boat!
Note: Broadcaster BSkyB was paid a total of £318 million as a final settlement of this dispute.



Agile Resources

Work Performance ManagementThe Easy WPM Workbook, is a practical spreadsheet that performs the calculations needed to implement Work Performance Management (WPM) on agile projects to calculate the status and anticipated completion dates based on the work performed vs the amount of work planned to be achieved at a point in time. Any convenient metric can be used, ideally one that is already part of the project management systems such as story points, function points or development hours.

To download sample files and see how the tool works see Easy WPM Workbook 

GAO Agile Assesment GuideGAO Agile Assessment Guide discusses best practices that can be used for Agile adoption, execution, and program monitoring and control. Use of these best practices should enable organizations to better transition to, and manage, their Agile programs.
Download the Guide.


Agile Alliance - the home of the 'Agile Manifesto' -

Best Management Practice products, UK Government (formally OGC, now Axelos) - the umbrella site dedicated to making access to information quick and easy: 
- PRINCE2 Agile - a complete agile project management solution:

Disciplined Agile (DA) tool kit from PMI -

SAFe Scaled Agile Framework a system for implementing Agile, Lean, and DevOps practices at scale -  

Agile Business Consortium - A not-for-profit organization, that pioneered Agile and has unrivaled expertise in the field:

Scrum AllianceⓇ - a nonprofit organization that is guiding individuals, leaders, and organizations with agile practices, principles, and values: 

SCRUMstudy - Global Accreditation Body for Scrum and Agile Certifications (owned by VMEdu):



Traditional Approaches to Software Development

The software development industry started in 1953 with the SAGE project, this was the first time a well defined software development methodology was needed to implement a program on a computer. Before this time initially the programming function was integral to the development of the physical computer, and later was done in the machine's operating code. At this time software engineering was assumed to be similar to other engineering disciplines and the management of software developments used the same approach, you created the plan for the work and then built to the plan. This approach is essential for most engineering projects such as construction, shipbuilding, aircraft manufacture, etc., it was soon found to be sub-optimal for software projects.

By the 1970s, various iterative and incremental development approaches to the development of large software projects started to emerge. The 1970 paper by Dr. Winston Royce 'Managing the development of large software systems' was one of the first to argue the need for an iterative approach to software development with prototyping.

This tend continued through the 1980s and 90s. Techniques such as 'Spiral', RAD, and Scrum appeared.

The Agile Manifesto (discussed above) published in 2001 consolidated these different methodologies into a common concept 'Agile' and has provided the foundation for the continued development of iterative and adaptive approaches to software development. 

Prs: The Effective Management of Time in Complex Projects. An ICT Perspective. The IT industry’s inability to effectively manage time has been widely documented. Other industries are no better, if the Burj Khalifa in Dubai had been built at the same speed as the Empire State Building (completed in 1931) it would have opened two years earlier! Research by the CIOB undertaken in 2007 found most complex/mega projects failed to adequately mange time, most finished late and the situation was getting worse over time. Interestingly, the degree of failure seems to be the same regardless of the size of the penalties imposed for late completion and regardless of the form of contract used.


The Waterfall approach to software development was formulated in DOD-STD-2167A published by the US Department of Defense in 1988. The waterfall model, requires the following phases to be followed in order:

  1. System and software requirements captured in a product requirements document
  2. Analysis of the requirements resulting in process models, database schema, and business rules
  3. Design of the software resulting in the software architecture
  4. The development, proving, and integration of software (coding)
  5. Testing, including the systematic discovery and debugging of defects
  6. Transition to operations including installation of the new program, migration of data to the new platform, support, and ongoing maintenance of the new system.

The waterfall model from the 1980s is based on the premise that the project should only move to a new phase when its preceding phase is reviewed and verified. However, waterfall can include slight or major variations on this process, including returning to the previous phase after flaws are found downstream, or returning all the way to the design phase if downstream phases identify major deficiencies.

The combination of a rigid framework, lack of senior management understanding of IT, poor management practices leading to over documentation, and long development cycles, created a situation where 'waterfall' became synonymous with bad management and poor project delivery. This poor reputation has been used by agile advocates to promote a better way of developing software and sell their services, a trend that is continuing.  However, it is important to note:
1.  Waterfall was a relatively late development - there were other agile software development methodologies
     in use before 'waterfall' and before the Agile Manifesto.
2.  The waterfall concept only applied to software development projects. Other engineering project
     require design to precede the building process and cannot go back and change 'built' work without
     incurring massive costs. 

The development of agile and the brief history of waterfall are detailed in A Brief History of Agile, part of our History of Agile, Lean, and Allied Concepts page. 

Care is needed to ensure everyone understands the project strategy.  Download our White Paper on Project Strategy.

Blg: The Problem with Waterfall. This post provides a brief history of Waterfall from inception to its abandonment in the 1990s, and argues the use of the term 'waterfall' in the 21st century is meaningless, no one is using waterfall, and no one know what the term is supposed to mean in a modern context. 

Download DOD-STD-2176A Defense System Software Development (1988).
Download Software Requirements are they really a problem, T.E. Bell and T.A. Thayer (1976).
Download Managing the development of large software systems, Dr Winston W. Royce (1970).


Useful External Web-links & Resources

Australian Computer Society (ACS) - Computer industry professionals:

ISBGInternational Software Benchmarking Standards Group - The mission of the ISBSG is to improve the management of IT projects through the use of public repositories of software engineering knowledge and metrics:

PGCS For papers on Agile presented at the PGCS Annual Symposium see:


A course in a book

Easy EVM

Communication Plan

Work Performance Management

Easy CPM

Risk Management Plan

Work Performance Management

EVM Work Sheet

Project Charter Template

Work Performance Management

Easy Stakeholder Management

Risk Register

Work Performance Management

Work Performance Management

A course in a book

Easy EVM

Work Performance Management