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

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 C

ha

pte

r N

o.

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 problems occur here

internet


Upstream System

Client System

2/12/2015


6



Needs Analysis Focus C

ha

pte

r N

o.

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 .....



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 problems occur here problems occur here too

2/12/2015


10



Lifecycle Stage Focus C

ha

pte

r N

o.

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



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



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 Ch

ap

ter

No

.

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


2/12/2015


18



Resource Focus C

ha

pte

r N

o.

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 21 2/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/2015

Team Focus & Project Success 23



Misfocus-caused error in software projects

Leadership & Management

Transcript of Misfocus-caused error in software projects