Introducing the Development Director

32
Part of a series taking a closer look at enterprise IT THE DEVELOPMENT DIRECTOR
  • date post

    21-Oct-2014
  • Category

    Marketing

  • view

    1.763
  • download

    1

description

Part of a series exploring enterprise IT decision makers. This presentation explores: Who are they? What are they responsible for? Who should be talking to them? What do they want to talk about?

Transcript of Introducing the Development Director

Page 1: Introducing the Development Director

Part of a series taking a closer look at enterprise IT

THE DEVELOPMENT DIRECTOR

Page 2: Introducing the Development Director

SOMETIMES IT FEELS LIKE THE ONLY ONE MARKETERS WANT TO TALK TO IS THE CIO

Page 3: Introducing the Development Director

BUT THERE’S A WHOLE LOT MORE TO ENTERPRISE IT

Page 4: Introducing the Development Director

INTRODUCING THE DEVELOPMENT DIRECTOR…

Page 5: Introducing the Development Director

CONTENTS

What else might I be

called?Who am I? What do I do?

What’s my typical background?

Who is my boss, and who do I manage?

A snapshot of the application development cycle

What might my objectives look like?A day in the life of the Development DirectorWhat do I think about the people I work with?

Who’s targeting me? (and who should be?)

Learn to speak ‘Dev Dir’

And what do they think about me?

Page 6: Introducing the Development Director

WHAT ELSE MIGHT I BE CALLED?

There’s a lack of consistency in naming for this job function. But some titles crop up repeatedly:

Systems Director/Manager

Head of Application Development

Business Systems Manager/Director

Director of Software Development

Head of Application Infrastructure (not often)

Information Systems Director (although this often means CIO)

Page 7: Introducing the Development Director

WHO AM I? WHAT DO I DO?

I’m responsible for:

• All applications/systems within the business (not systems software)

• In-house/bespoke systems + packages

• Laptops/smartphones to the mainframe

• Interface to all the business streams/departments

Page 8: Introducing the Development Director

WHO AM I? WHAT DO I DO?

I typically:

• Design and build applications/systems (but I don’t run them)

• Buy and take responsibility for packages

• Maintain applications/systems (I worry about availability)

• Manage the entire cycle from business requirements to live running working directly with the business

• Understand what the business needs/what its strategy is

• Manage third parties (in the outsourced world)

Page 9: Introducing the Development Director

TYPICAL BACKGROUND

• I probably started life as a developer, maybe as a business analyst, but probably not a tester or software support guy

• The new breed may come from a consultancy background

• I might have a degree in programming, although I probably haven’t written a line of code in years

• I may have a degree in maths or languages

Page 10: Introducing the Development Director

TYPICAL BACKGROUND

• The best of us have a ‘strategic emphasis’

• We line up well with the business and manage downstream the production of what the business needs

• We like apps, and may take infrastructure for granted (treat it as a utility)

• We may identify with the business more than our colleagues in IT do (we’re strategic, they are not ….)

If a system fails,

its probably the

infrastructure, or…

Page 11: Introducing the Development Director

WHO IS MY BOSS, AND WHO DO I MANAGE?

IT Strategy and

Architecture

Business Transformatio

n

Application Developme

ntOperations

Governance and Risk

CIO

Dev MgrBusiness Area

1

Dev MgrBusiness Area

2

Dev MgrBusiness Area

3

Dev MgrBusiness Area

4

Dev MgrDesktop

Smartphone Apps

Page 12: Introducing the Development Director

ABOUT THE APPLICATION DEVELOPMENT CYCLE

A never ending process…• Core systems can be over

20 years old• Package cycle vs bespoke

cycles• Need to get the analysis

right• Need to get the design

right• Testers get the flak

Page 13: Introducing the Development Director

ABOUT THE APPLICATION DEVELOPMENT CYCLE

Need to keep up with issues like:• New product launches• Regulation• Performance• User interface consistency• Batch• Costs• Skills

Page 14: Introducing the Development Director

WHAT MIGHT MY OBJECTIVES LOOK LIKE?

Go live on a new business system by end second Quarter – and secure whatever business performance benefits are expected

Achieve 99.9% app availability

Meet any other specific business measures that are dependent upon my apps

Customer satisfaction rating (keep business unit heads happy)R

edu

ce m

y c

ost

s by 1

0%

Increase productivity by 10% (do more per developer)

Main

tain

good

sta

ff

rete

nti

on

Sou

nd

man

ag

em

en

t of

thir

d p

art

y S

LAs

Page 15: Introducing the Development Director

A DAY IN THE LIFE OF THE DEVELOPMENT DIRECTOR

Catch up with CIO

Interview – Head of [example business unit] Systems (largest people role)

Planning meeting – [example business unit A]Planning meeting – [example business unit B]

Lunch – high performers (retention)

Vendor meeting – package X

New Dev plan to review with CTO (incl. new dev platforms)

Review with Ops (SLAs)

Demo – [example Y] system prototypeReview meeting – [example Z] department

Page 16: Introducing the Development Director

WHAT DO I THINK ABOUT PEOPLE I WORK WITH?

CIO – “I could do that job better”

Ops Dir – “bit of a grease

monkey/pseudo techie”

CTO – “technically strong but practically

inept”

Strategy/Transformation Dir – “on Planet Zogg’”

Compliance/Security – “Ah, the Business

Prevention team”

Page 17: Introducing the Development Director

AND WHAT DO THEY THINK ABOUT ME?

“Takes ages to build something a grad could

pull together in a weekend…” (CTO)

“Doesn’t really understand

the business” (Business

heads)

“Slopey shoulders… ‘It’s never a problem with

the app’” (IT Ops Director)

“Why do they have so many people? What do they all do?” (Various)

Page 18: Introducing the Development Director

WHO’S TARGETING ME? (AND WHO SHOULD BE?)Anyone who sells:

• Applications development platforms, or infrastructure for the delivery of applications

• Often broad technology solutions for business

• All kinds of business applications

Page 19: Introducing the Development Director

GLOSSARY:LEARN TO SPEAK DEV DIR

Page 20: Introducing the Development Director

GLOSSARY: LEARN TO SPEAK ‘DEV DIR’

PackageA way of describing the various functionalities of an application. What’s in the package? – basically a list of things it can do. Different releases can add to these functionalities (hopefully the application has been well written to make this process easier).

Bespoke packageBespoke application – we’ve looked at all the available packages – none do quite what we want, so we’re going to build one ourselves, write it internally with our own developers (or contracted ones)and build it directly to our precise specifications.

LicenceThe agreed rules and restrictions for use of specific systems software or applications software. e.g. You’ve got 100 user licenses in two countries for the fee you’re paying – and no more! It can get very complex to control access across a large organisation with multiple offices (people download or share passwords), so it can be easy to fall out of compliance.

Page 21: Introducing the Development Director

GLOSSARY: LEARN TO SPEAK ‘DEV DIR’

Support and maintenanceThis is often rolled into one term but think about it as two: • Support: we provide support if users can’t do something they want to – typically

through the Helpdesk. • Maintenance: this is fixing the ‘bugs’ – faults with the application itself.

Software as a ServiceA software delivery model in which software and associated data are usually centrally hosted on the cloud (it doesn’t have to be in the cloud though, however you do it, it is effectively renting the software).

It has become a common delivery model for many business applications and has the potential to reduce IT support costs by outsourcing hardware and software maintenance and support to the SaaS provider.

Page 22: Introducing the Development Director

GLOSSARY: LEARN TO SPEAK ‘DEV DIR’

System software vs application softwareSystem Software is any computer software which manages and controls computer hardware so that the application software can perform a task. You need System Software to run an app. Operating systems, such as Microsoft Windows, Mac OS X or Linux, are prominent examples of System Software.

Application software refers to programs that enable the end-user to perform specific, productive tasks, such as word processing or image manipulation. Examples include Microsoft Word, Excel, or Adobe Photoshop.

Application development backlogThis is all about delivery timescales. E.g. I’m head of cards systems in a bank and you’ve given me ten things you want. Five are in process but I’ve got a backlog of the other five. I’ll give you an estimate of when you can get it developed by, and that backlog is measured in ‘man years’. This can be as many as hundreds of ‘man years’ – which is why Apps development teams are so big!

Page 23: Introducing the Development Director

GLOSSARY: LEARN TO SPEAK ‘DEV DIR’

Offshore developmentWhere much of the development work is done in more cost effective (lower paid!) countries. These are teams of apps developers overseas who respond to a brief, and design software around it.

Onshore/offshore modelWhere application development (in this case) is managed by a locally based project manager who coordinates with an offshore group of developers.

OutsourceHand over the process of applications development, management and maintenance to a third party. Then manage relations with that single third party.

Page 24: Introducing the Development Director

GLOSSARY: LEARN TO SPEAK ‘DEV DIR’

Right sourceRight sourcing evaluates all outsourcing options in order to bring together the best combination of onsite, offshore and near-shore delivery capabilities to provide maximum cost and time advantages. A balance is sought between those applications and processes that can be executed using internal resources and those that call for outsourcing. Factors which affect the sourcing strategy for the application include, but are not limited to, application criticality, complexity, stability, technology base and availability of documentation.

Visual development tools/prototypeThis is when you design a basic workable ‘dummy’ version. Put one case through – to show how it works. A bit like a concept car – that doesn’t really drive round the whole track in all conditions. Where you might have a button that will show 20 things when finished, right now it’s only got a few critical things that work. This is to give the impression of what the full working system will look like and get approval from the user.

Page 25: Introducing the Development Director

GLOSSARY: LEARN TO SPEAK ‘DEV DIR’

The life of the Development Director

SpecDefining the specifications for a new application – what does it need to achieve and under what circumstances? Involves a lot of discussion between the developer delivery team and the end users – basically understanding the business challenges and how to address them. These will be a key part of acceptance testing later. The end result needs to be signed off to go forward. It’s the document the business often doesn’t read but should.

DocumentationInformation about developing applications and drivers for a certain operating system. These are statements that identify attributes, capabilities, characteristics, or qualities of the app. This is the foundation for what gets implemented. At a technical level this would include the code, algorithms and interfaces the app will have.

Training – to be apps ready Training for employees can vary significantly according to the role they fulfil and how they will use the application. Need practical training to get benefits fast and minimise business disruption.

Page 26: Introducing the Development Director

GLOSSARY: LEARN TO SPEAK ‘DEV DIR’

The life of the Development Director

Business representativeThe person on the ‘business side of the fence’ in the organisation who signs off what the users want. When we’ve done all the workshops etc. we can eventually get that signed doc that shows everything we want.

User requirements Need to workshop it through with the business representative. Then play this back in detail – going through each data item by data item – they need to read this in detail. What the employees or customers will use the applications for – what is the business need and the specific problems it must solve?

Development tools Software that the developers can use to create a new application. Good tools will help them get the job done faster (meaning more organisational flexibility for IT and the business). They often incorporate web and collaboration technologies, open platforms, and extensible frameworks. Some will be visual, some won’t.

Page 27: Introducing the Development Director

GLOSSARY: LEARN TO SPEAK ‘DEV DIR’

The life of the Development Director

Testing and automated/regression testingTo simulate what a user does, how the application behaves and to root out any bugs you can build a test ‘harness’. You’d probably get some users in to physically test it too. What about regression testing?

Let’s say you test elements one to ten and all is fine. But then you find a problem with number eleven. So you fix it. But by rewriting the code to fix it you might have altered something in those original one to ten elements. So you then have to go back (regress) and check one to ten still work. That’s regression testing, and it can get pretty complicated when you do it on a larger scale.

You’re not going to go live with a system until you know it works at high volume. This is stress testing. You create a harness that simulates 10,000 users. It models when systems start to grind to a halt. Important to know what scale it starts to fail at.

Page 28: Introducing the Development Director

GLOSSARY: LEARN TO SPEAK ‘DEV DIR’

The life of the Development Director

UAT (User Acceptance Testing)Acceptance Testing is conducted to determine if the requirements of the application have been met. You hand over to the business side of the fence and say ‘use it to do what you need and flag any problems’. When it’s signed off you are saying that it’s safe to go live. If it goes live, and any bugs appear, it’s your fault not ours!

Legacy/heritage systems Old (but not necessarily obsolete!) computer systems that may still be in use because their data cannot be changed to newer or standard formats, or their application programs cannot be upgraded. Sometimes it can be difficult to know if anyone still knows how to fix it in the organisation!

Page 29: Introducing the Development Director

GLOSSARY: LEARN TO SPEAK ‘DEV DIR’

The life of the Development Director

Batch progammingOvernight – batch programs run the overnight processes – like.

RTFMRead The F***ing Manual. The response you usually get from the helpdesk when users call up to say the application is not working!

Source vs object The programmer writes code in a textual form or using a visual programming tool (source code), and this code is translated (by a program called a compiler) into another form (object code) which can be executed directly by a computer. The code is then distributed in object code form. Basically, object code is only useful to the user – you can’t work with it to change the application.

Page 30: Introducing the Development Director

WHO ARE WE AND WHY DO WE CARE?

Page 31: Introducing the Development Director

ABOUT THE MARKETING PRACTICE

• With over 90 people and 10 years’ growth we are 100% B2B focused and one of the UK’s top 10 B2B agencies

• We integrate all the skills you need under one roof to plan and manage end-to-end programmes across EMEA (data, inside sales, creative, content, digital …)

• And we focus on working with a few select clients to deliver results and prove ROI

We live and breathe enterprise demand generation

Page 32: Introducing the Development Director

TO TAKE A ONE-MINUTE TOUR OF THE MARKETING PRACTICE, VISIT:www.themarketingpractice.com/the-agency