We know that many projects fail, or become impaired, but what is the reason given so many methodologies, tools and support systems. Error comes from many places. For whatever reason, teams create problems by investing more time in aspects of software development practice that have a smaller impact on project overall success, and accordingly invest less time in areas that have a larger impact.
How Software Developers Destroy Business Value.pptx
Misfocus-caused error in software projects
1. Project Team
Focus & Project
Success
Focus Created Error in Software Development Projects
By Adam Russell, 2nd December 2015, v1.0
http://adamonprojects.com
2. Date
title
Page
Introduction
2/12/2015
Team Focus & Project Success
2
Many projects fail or become impaired, but what is the cause? Software development is one of the most complicated
endeavours mankind has ever undertaken, but after 70 years of progress, huge investment in tools & methodologies,
and constant research on the causes of failure, many projects still fail or materially underperform.
In this short presentation, we take a high-level look at some error-creating tendencies in project team focus that I’ve
observed over many projects, both using waterfall and agile approaches. These observations are qualitative and
generalised, and relate to no specific organisation or project. I make no claim on causation, these are external
observations of tendencies that exist in projects that had delivery problems.
For whatever reason, teams create problems by investing more time in aspects of software development practice that
have a smaller impact on project overall success, and accordingly invest less time in areas that have a larger impact.
These observations are not saying that teams “do all of one thing and none of that”. They are saying “projects with
errors tend to focus more on ‘this’ and less on ‘that’, but ‘that’ is where bigger impact errors likely arise”.
These observations are aimed to make us think about what we are doing, and to shape behaviour to focus on those
areas that give a more productive and less error prone project execution. We need to understand the causes this type
of misalignment, and to find some answers on how prevent it, or having found it, re-align focus for success.
I think the answer is not in more tools, methodologies and process. The answer is a principle-based approach to how
teams delivery software projects. From principles we can make objective behaviour assessments that drive a simpler
approach based on reality, not desire: we look at things the way they are, not the way we hope or want that they are.
http://adamonprojects.com
3. Date
title
Page
5 Common Areas of Misfocus
2/12/2015
Team Focus & Project Success
3
1. App Functional Focus
2. Needs Analysis Focus
3. Lifecycle Stage Focus
4. Practice Focus
5. Experience Focus
http://adamonprojects.com
5. Date
title
Page
App function bias vs interface
2/12/2015
Team Focus & Project Success
5
• Open source and componentised architectures allow architects and
developers to easily focus on development of a system’s core
functions. A plethora of interface ‘standards’ make it easy assume that
interface development will be simple and therefore this implementation
can be done later, or will require less time.
• But “standards-based” components can often be standard in name
only, and can result in unexpected errors and gaps.
• Even without component defects, developing interfaces have more
overheads and problems than application components.
• And the problems tend to arise later in projects, and are harder to
debug and fix.
http://adamonprojects.com
6. Date
title
Page
Component Focus
Focus on app components over interfaces
App
App server
App
App server
Most of the
attention
goes here
Most of the attention
goes here
Most of the problems occur here
internet
Most of the problems occur here
Upstream
System
Client
System
2/12/2015
Team Focus & Project Success
6
http://adamonprojects.com
7. Needs Analysis
Focus
ChapterNo.
Focus on functional needs over quality,
UX or performance needs when missed
non-functional needs can cause problems
that are harder to diagnose and fix.
8. Date
title
Page
Needs Analysis
2/12/2015
Team Focus & Project Success
8
• Whether using traditional Requirements Analysis or User Stories, teams in
impaired projects tend to focus more heavily on statements of “functional” need,
& less on quality, performance or other “non-functional” needs.
• In extreme situations, non-functional requirements (NFR’s) get only cursory
analysis, or the risk responsibilities are artificially transferred to other teams.
• And yet NFR’s missed or in defined in error tend to have far more impact on the
project, and can be much harder to fix, than missed or incorrect functional
requirements.
• Achieving an unexpected service level metric can often impact core
architectural decisions made early in the project, which are very costly to
rework late in a project.
http://adamonprojects.com
9. Date
title
Page
→ It shall ......
→ It shall .....
→ It will .....
→ It must .....
Most of the attention
goes here
Most of the problems
occur here
Functional Requirements Non-functional Requirements
→ Responsiveness
→ Throughput
→ Usability
→ Security
→ Accessibility
→ Reliability
“Traditional” Requirements Specification
most time spent on functional requirements
2/12/2015
Team Focus & Project Success
9
http://adamonprojects.com
10. Date
title
Page
Agile Needs Analysis:
User Stories tend to emphasise “I want”
As a ..................... , I want ...................... , So that......................
Most of the attention goes here
Most of the problems occur hereproblems occur here too
2/12/2015
Team Focus & Project Success
10
http://adamonprojects.com
12. Date
title
Page
Project Lifecycle
2/12/2015
Team Focus & Project Success
12
• The back-end of a project (code build, test, deployment) is usually far
more organised and focused than the front-end (customer needs
analysis, scoping, architecture).
• Teams in impaired projects tend to focus more on this back-end as
the “real” project and where the “real” work gets done.
• But the work up-front is at least an order of magnitude more influential
to project success than back-end work.
• Think of Boehm’s “Cost of Change” curve, where lost time and its
impacts are considered as defects.
• Even just the failure to prosecute the project rapidly can cause errors.
http://adamonprojects.com
13. Date
title
Page
Elapsed Time
Scoping Requirements
Solution
Design
Design and
Build
Integration
and Test
Deployment
Most of the attention
goes here
Most of the problems
occur here
Customer
Problem
Aligned to Deterministic Planned Lifecycle (e.g. PMBOK-based or PRINCE)
Project Lifecycle (Waterfall)
Back end dev is emphasised over upfront initiation
2/12/2015
Team Focus & Project Success
13
http://adamonprojects.com
14. Date
title
Page
Elapsed Time
Business Scoping Solutioning Inception
Construction
Iterations
Transition /
Release
Integration
Most of the attention
goes here
Most of the problems
occur here
Customer
Problem
Aligned to agile lifecycle e.g. Scrum
Generic Agile Project Lifecycle
Back end development is emphasised over initiation.
Operations
2/12/2015
Team Focus & Project Success
14
http://adamonprojects.com
16. Date
title
Page
Practices Focus
2/12/2015
Team Focus & Project Success
16
• Development practices of code build, test, deployment are usually far
more organised and focused than the front-end practices of customer
needs analysis, scoping, and architecture.
• User Experience practises produce output that is at least an order of
magnitude more influential to project success than development, but
nett effective input can get crowded out by development practise
timelines
• User Experience tends to focus on visual style practises rather than
more enabling interaction modeling and information architecture
practises
http://adamonprojects.com
17. Date
title
Page
Most of the
attention goes
here Most of the
problems
occur here
User Experience vs Application Development
An emphasis on functionality over User Design / UX
2/12/2015
Team Focus & Project Success
17
http://adamonprojects.com
UX Practices
Dev Practices
18. Date
title
Page
Most of the
attention goes
here
Fonts, designs, colors
Information Architecture,
Workflow, User journey
User Experience
Visual "Look and Feel" emphasised over Information Architecture
Most of the
problems occur
here
2/12/2015
Team Focus & Project Success
18
http://adamonprojects.com
19. Resource
Focus
ChapterNo.
Its common to underestimate the
expertise required to realise any given
solution – easy to focus on the available
resources rather than what we need
20. Date
title
Page
Skills & Experience
2/12/2015
Team Focus & Project Success
20
• Organisations rarely decide to forego a project if there is doubt about whether
a person or a team has the right skills – unless it is a landmark project.
• There is a common tendency to underestimate the level of skill and experience
required to implement any given project.
• Organisation will frequently decide to manage the situation with existing
personnel, even in some “hybrid” mode with a more experienced person
supporting a more junior person.
• Budgetary constraints and company pay-bands or rate limits can cut-off
access to the experience actually required because these are optimised to the
most likely level required, and as we often see (see over), this is often too low
to attract the right people.
http://adamonprojects.com
21. Date
title
Page
Operating basic
processes and being
‘driven by their
projects’ rather than
the opposit
Managing to just stay
on top of their projects,
but working long hours
and stressed.
8-12 Years
Were happier and
more in control of their
projects, which were
larger but performing
better
3-5 Years < 3 years (Avg 1.4)
PMs that thrive have much more experience
From a large enterprise PMO, we assessed who was
“thriving” in the enterprise environment and who was
struggling, and compared to the criteria for which we
were hiring. The single biggest discriminator was years
of PM experience, almost exclusively. We were hiring
for about 5 years experience, but the folks who thrived
had around 10 years experience.
PM Experience Distribution
212/12/2015
Team Focus & Project Success
This is what
we were
hiring for: 3-5
Years
These are the
folks who
were “thriving”
http://adamonprojects.com
22. Date
title
Page
Conclusion
This list of observations is by no means definitive, but it does address a number
of areas that have high leverage during project execution.
There are probably dozens of practices within the field of software development
projects that can have an effect on project impairment if not balanced correctly.
Only the project team can decide whether they are doing to much or too little of
some particular practice: I am not mandating any particular change in a general
presentation such as this.
But from my experience the ones I’ve listed here are very well worth a look: to
take some investment of time to review whether you are seeing symptoms that
could be caused by mis-focus in these areas.
Another way to look at this is to think of the relative focus of your project team
as your “perspective” on the project delivery. If you get your “perspective” right
then you’ll deliver well.
http://adamonprojects.com
23. “What a team focuses on
predicts project success”
Find out more on
http://adamonprojects.com
2/12/20
15
Team Focus &
Project Success23