DPM:UK 2014 Q&A Discussion panel

My notes from the Q&A panel at DPM:UK 2014.

  • Helen Holmes, Senior Project Manager, Code ComputerLove – manages team of 13, larger projects.
  • Lisa Vigar, Senior Product Manager, BBC North – CBeebies, strategy, dealing with scope + stakeholders.
  • Ian May, Programme Director, Creative Jar – manages PMs, process
  • Hosted by Paul Boag

Do you use prototyping?

Rapid prototyping. Used more, when working on CBeebies site important to test with children.

Use Axure to help build wireframe prototpyes. Stick them on Facebook/Twitter, see if people engage.

Developers vs creatives. Developers like things written down / scenarios. Creatives want to do things visually / storyboards. Need something in-between, lack of written instructions lead to mis-understanding.

How did you become a PM?

Wanting to make things, realising you need other people’s skills to do this.

Advice to people starting out as a PM

Don’t do everything yourself, get the right people to help you
Build your own toolkit, methodology
Learn about methodologies, use what works for you
Every project is different, it’s not one size fits all

Does agile suit web projects?

1) Take from it what you can, scrums, standups, retrospective

Fixed price projects: scope is flexible. Needs to be clearly communicated.

2) In one recent agile example (complex tech web build) the client didn’t understand, though it meant we were flexible but not them. Problem was client expectations.

Made the mistake of running sprints consecutively, need gaps inbetween.

3) BBC. We work internal & with clients. What do people mean by agile? Set scope at beginning, has degrees of change through project. Easier with an internal team (scrum).

Lifecycle of a CBeebies project “Playtime” app. Worked with mobile agency in Bristol. They worked in sprints, but not fully agile. Methodology is up to external agencies, we need to come to agreement with them. Very difficult with contracts if the agency wants complete flexibiity (agile).

Agency scheduling

We are agile, but not true agile. Use parts that work for us.
pre-sprint planning week in advance. Sprint needs to be signed off by client before sprint starts.

If a team works together we try to isolate them together.
Not easy, try to make sure there are two devs who can work on every single client.
Developers don’t like context switching, we try to plan to minimise this. We have a maintenance team who are easier to disrupt.

SLAs, we have this with important clients (Oxfam) so we can respond to issues.
We have rigorous testing, so issues are often not code issues.
Headscape have a fixed day each week for maintenance work.

Pitfalls of going agile

– continually train team, enforce routines (scrum)
– know your stuff and persevere
– From product point of view is educating senior stakeholders (the old boys)

How much documentation do you need?

– TargetProcess used to manage user stories
– Need user stories across all requirements as a minimum requirement

– Client-side you need technical documentation if someone else is going to pick up the code
– Depends on project

– Documentation at start of project is most important
– You need a good relationship, more important than documentation

– Documentation can change, need to recognise this

Impact of responsive design on web projects

– Lot more clients are demanding
– Changes how we approach projects, mobile up
– Design: designers decide breakpoints & grid system
– Biggest challenge – understanding the most efficient way to work, get client buy in, change how internal design team think

– Content is a big challenge, often multimedia not just text
– How do you make games work acros different platforms
– QA can go astronomical
– Defintely a game-changer

– We did UX, another agency did creative (a print agency)
– Didn’t work, we had to teach them how to do responsive design for free

Agile, client buy in – do they attend all sprint planning meetings?

– Can work, client came in twice a week on a large project
– Smaller projects quite difficult. Generally do remote reviews
– Demos are done via screenshare, retrospectives via questionnaires

– BBC. We work with companies all over the country, so can’t go very regularly to meetings.
– Difficult to get a single sign-off in BBC in practise.

Estimates

– Make a list of everything that has to be done. Guess, show it to designers/devs for review
– BBC. Used fibonacci sequence, comparitive estimation. Not too exact. Internal teams.
– Get the people who are going to do the work to do the estimates

Agency perpective

– One of the most difficult parts of the job
– Ballparking first to get buy in from team
– Firm up as learn more

Managing teams that are in different locations

– Quite difficult
– Tools help, conf calls, Skype, shared documents
– Regular standups can help

– Did front-end/back-end work with USA and UK company. Very hard
– All about communication