Slides used in workshop session B1 on "It Always Takes Longer Than You Think (Even If You Think It Will Take Longer Than You Think)" at the IWMW 2004 event held at the University of Birmingham on 27-29 July 2004. See http://www.ukoln.ac.uk/web-focus/events/workshops/webmaster-2004/sessions/walker/

1. 1
It always takes longer than you
think - even if you think it will
take longer than you think.
Reflections on project management
Pete Walker, Internet Development Manager
peter.walker@bristol.ac.uk

2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 28
Project team (2) - Belbin team
roles
• Plant
• Coordinator
• Monitor/Evaluator
• Implementer
• Complete Finisher
• Resource
Investigator
• Shaper
• Team Worker
• Specialist

29. 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. 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. 31
PM buzzword bingo
• SSADM
• DSDM
• XP
• RAD
• UML
• UCD
• ROI
The useful ones?
• CYA
• POF
• MoSCoW
• PMWT
• 3 C’s

32. 32
QUESTIONS?
Peter.walker@bristol.ac.uk
http://www.ilrt.bristol.ac.uk