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. http://adamonprojects.com

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Misfocus-caused error in software projects

More Related Content

What's hot

Viewers also liked

Similar to Misfocus-caused error in software projects

Recently uploaded

Misfocus-caused error in software projects