Misfocus-caused error in software projects

Project Team
Focus & Project
Success
Focus Created Error in Software Development Projects
By Adam Russell, 2nd December 2015, v1.0
http://adamonprojects.com

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.

Date
title
Page
5 Common Areas of Misfocus
2/12/2015
3
1. App Functional Focus
2. Needs Analysis Focus
3. Lifecycle Stage Focus
4. Practice Focus
5. Experience Focus

App function
Focus
ChapterNo.
More focus on application components
than the interfaces between them,
when interfaces often cause the most
problems.

Date
title
Page
App function bias vs interface
2/12/2015
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.

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
6

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.

Date
title
Page
Needs Analysis
2/12/2015
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.

Date
title
Page
→ It shall ......
→ It shall .....
→ It will .....
→ It must .....
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
9

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
10

Lifecycle
Stage Focus
ChapterNo.
More focus on the build, test, deploy
back-end stage of the project lifecycle
than the scoping and inception stages.

Date
title
Page
Project Lifecycle
2/12/2015
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.

Date
title
Page
Elapsed Time
Scoping Requirements
Solution
Design
Design and
Build
Integration
and Test
Deployment
goes here
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
13

Date
title
Page
Elapsed Time
Business Scoping Solutioning Inception
Construction
Iterations
Transition /
Release
Integration
goes here
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
14

Practice Focus
ChapterNo.
More focus on Development practices
(the realisation of the solution) than
the User Experience practices.

Date
title
Page
Practices Focus
2/12/2015
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

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
17
UX Practices
Dev Practices

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
18

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

Date
title
Page
Skills & Experience
2/12/2015
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.

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
This is what
we were
hiring for: 3-5
Years
These are the
folks who
were “thriving”

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.

“What a team focuses on
predicts project success”
Find out more on
2/12/20
15
Team Focus &
Project Success23

Misfocus-caused error in software projects

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (10)

Similar to Misfocus-caused error in software projects

Similar to Misfocus-caused error in software projects (20)

Recently uploaded

Recently uploaded (13)

Misfocus-caused error in software projects