1 it always takes longer than you think - even if you think it will take longer than you think....

Post on 28-Mar-2015

215 Views

Category:

Documents

1 Downloads

Preview:

Click to see full reader

TRANSCRIPT

1

It always takes longer than you think - even if you think it will take longer than you think.

Reflections on project managementPete Walker, Internet Development Managerpeter.walker@bristol.ac.uk

2

What’s it all about?

• The delights of project management– Mainly from the developer’s perspective

• Not another methodology– Tips, tricks, techniques, clichés, trite little sayings,

wise sayings, my mistakes, etc

• I won’t solve all your problems• I won’t answer all your questions

– but please ask questions at any time

• I will save you time and money!

3

Why am I here and what do I know?• 15 years IT experience• Programmer/DBA/Project Manager in Local

Government – Oracle, PL/SQL, Paradox and other PC apps

• Software Development Manager at Emis/Capita FHE– Student record systems for FE & HE– Oracle, VB, client-server

• Software Development Manager with Swift– Stock control, financial and manufacturing systems– Ingress database and 4GL

• May 2001 - joined ILRT

4

What does ID group do?

• Web sites and applications – CMS for University of Bristol, C of E, LTSN-Best– Online survey software, car share software– UCISA, SCONUL, HESDA, Leadership Foundation– Departmental VLE’s– Course Online Booking System– eLearning apps

• 10 staff plus others from ILRT and IS• Open-source• Quasi-commercial• 50% UoB/50% external

5

A lot to cover – the rest of this session• Definitions• Knowledge• Alarm bells• Requirements• Project scope• What the client must

do• How much and how

long?

• Planning• Communication• Handling change• We’re late!• Finished?• Measuring outcomes• Project team• Questions

6

Definition time – “To manage”

• Poster worthy?– Be successful, achieve a goal, be in charge of, act

on, deal successfully, control

• Sometimes necessary!– “achieve something by trickery or devious methods”

• Reality? (Struggle, frustration, just-about-do-it) e.g.– “We just managed to catch the train in time”– “He managed to convince them”– “We managed to hide the fact that the widget did

not actually work yet”

7

To project manage (1)

• You must play office politics• Knowledge leading to control• Lots of administration• Gain respect and authority (aka: at least

look as if you know what you are doing!)

8

To project manage (2)

• You are being watched!• You are not expected to be expert on everything• Expertise not through knowing but knowing

where to find out• 3 C’s

– Commitment– Communication– Coordination

• Despite the above - you need to know a lot of things!

9

Knowledge

• Professional knowledge e.g software, methodologies

• What projects have we got on and where are they at?

• Whose working on them, what are their skills?• What’s coming up next?• Costs (and ideally success criteria/ROI)• Milestones, deadlines• Customer comments – good and bad• Timesheets, Bug lists, Wash-up meetings

10

Project initiation - Alarm bells!• Nobody’s project (or no one important) – you need a

project sponsor• No long term budget (initial spend only 30% of total)• Multiple customers/stakeholders• People think it is only a technical project• The job has to fit a budget not the other way round• Multiple dependencies• Potential feature creep – “oh and it could do this”• No idea where this project fits with institutional goals or

strategies• Have all this responsibility but not any authority

11

Requirements - what do you want?• System requirements – the BIG problem?• Users WILL change their minds (for sure,

always, every time, without fail…)• They will never get everything• MoSCoW• “Must Have” V “Should have”?• Do you still want the system if you do NOT

get this feature?

12

You won’t get this…

• “Out of scope”- List what you won’t do• Don’t assume anything – check and

agree• Client contact may change – write it all

down• You WILL miss something• Write it down for next time - keep

standard text• Get someone to sign (CYA)

13

What the client has to do and when• Tell them what to do and when e.g.

– How many meetings?– Arrange for staff (particularly senior) to be available?– How long to review documents or designs?– Buy licences? – Sort-out domain names?– Prepare content (major)?– Convert data, etc?

• Penalties for being late! • Customer is always right? – not necessarily!

14

Biggest Knowledge gap? How much and how long?• We’re all optimists - PMWT• Resist giving ball-park figures for cost or time• “I know this bloke wot wrote …”• “Gutless estimating” (Brooks)• Function-point analysis?• Metrics • Are you good at estimating – be honest!• Get estimates from project staff (buy-in)• Are your staff good at estimating – be honest!

15

We just don’t know!

• Most importantly - CYA• Tell the customer (more than once)• Try to better define requirements• Get paid for an analysis and specification

phase?• DSDM?

– Fix dates and budget but be flexible on functionality– Prototype– Time box– Cooperate – client as team member

16

Planning (1)

• Define scope before planning• Emperor’s clothes?• Public plan and real plan?• Gantt chart, Excel, Word?• Plan and then throw it away?• Effort V Elapsed – 3 day week?• Specific points in the year – guide not

determine e.g.– Start of the academic year– “It will be over by Christmas”

17

Planning (2) - What to include

• Analysis• Specification

(iterations?)• User interface design

(iterations?)• Development phases• Testing (and fixes!)• Content preparation• Documentation

• Holidays?• Server set-up?• Document review?• User acceptance?• Project

management?• Admin?• Meetings?• Milestones

18

Planning (3)

• Project Risk log – What’s the worse that could happen?

• What risks do you make public? (CYA)

• Will the customer overrun – do you risk it?

• Communication plan

19

Communication (1)

• Communication plan– Audience. Who should receive the communication? – Reason. Why you are communicating with them.

Why are they a key stakeholder. – Event. The communication, be it a weekly report, or

a presentation, or seminar– Responsible. Who is responsible for preparing and

scheduling the piece of communication. – Medium. The way in which it will be delivered. – Timing. How often it will be presented. – Content. What it will contain. This should address the

reason the audience will be interested in the project.

20

Communication (2)

“Communication is not saying something; it is being heard [and understood]”

• People hear what they want to hear; it suit their needs

• Write things down (CYA)

21

We’d just like to change…

• Change is inevitable, accept it (but not too readily!

• It never pays to be helpful!• Communicate & CYA

– Who is asking for it?– Get exact details– Impacts and risk– Write it all down– Get authorisation

22

Doesn’t time fly!!

• How does a project go late – one day at a time• Why?

– Hidden requirements– Changing requirements (poorly managed)– Under-estimation– Technology– Illness, staff leaving

• When development is 90% complete the project is only two-thirds done.

23

POF?

• Out of control, getting worse, redeemable but only if you act now.

• Communicate - tell the customer – talk to them (even if there is nothing much to say)

• Don’t throw resources at it!• Cut functionality rather than extend deadlines• If you do extend deadlines then make it

realistic (only do it once)

24

Technology

• Often the least important factor but…• Never use new technology on a

time/business critical project• NEVER use new technology on a

time/business critical project• Buy V Build – it depends….• Don’t lock-in content

25

When its “finished”

• Only finished when no one is using it anymore

• Wash-up – how was it for you? Good bits as well as bad

• Maintenance – 20% of initial budget?– Initial cost only 30% of lifetime cost

• Don’t rely on one person – spread the knowledge

26

Measuring the outcomes ROI

• Number of users• Increased sales• Intangibles – image, lack of legal

action, etc• Site usage stats – misleading• People forget the past – point to

achievements

27

The project team (1)

• You need a mix – From gurus/high-flyer through to plodders

• Assign responsibilities– try to avoid single expert– Assign the Cardboard cut-out developer?– Office Whiteboard of who’s doing what

• Keep people involved and informed• Belbin team roles

http://www.belbin.com/

28

Project team (2) - Belbin team roles• Plant• Coordinator• Monitor/Evaluator• Implementer• Complete Finisher

• Resource Investigator

• Shaper• Team Worker• Specialist

29

Pitfalls

• Governance at the expense of leadership?

• Becoming defensive• “It’ll never work” - focus on the

negatives • Lose enthusiasm• Not prepared to take risks

30

Do I practice what I preach?

• No• I still under-estimate• I often regret not writing things down• I don’t say “no” enough• I still sometimes let keen developers

use new technology• …and always regret it!

31

PM buzzword bingo

• SSADM• DSDM• XP• RAD• UML• UCD• ROI

The useful ones?• CYA• POF• MoSCoW• PMWT• 3 C’s

32

QUESTIONS?

Peter.walker@bristol.ac.ukhttp://www.ilrt.bristol.ac.uk

top related