Transcript It always takes longer than you think even if you take

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
[email protected]
1
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!
2
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
3
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
4
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
5
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”
6
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!)
7
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!
8
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
9
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
10
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?
11
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)
12
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!
13
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!
14
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
15
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”
16
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
17
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
18
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.
19
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)
20
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
21
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.
22
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)
23
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
24
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
25
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
26
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/
27
Project team (2) - Belbin team
roles
•
•
•
•
•
Plant
Coordinator
Monitor/Evaluator
Implementer
Complete Finisher
• Resource
Investigator
• Shaper
• Team Worker
• Specialist
28
Pitfalls
• Governance at the expense of
leadership?
• Becoming defensive
• “It’ll never work” - focus on the
negatives
• Lose enthusiasm
• Not prepared to take risks
29
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!
30
PM buzzword bingo
•
•
•
•
•
•
•
SSADM
DSDM
XP
RAD
UML
UCD
ROI
The useful ones?
• CYA
• POF
• MoSCoW
• PMWT
• 3 C’s
31
QUESTIONS?
[email protected]
http://www.ilrt.bristol.ac.uk
32