View source for The Art of Project Management: Knowing Where You Are in a Project, and What You Can Do When

=== Description ===

One of the keys to success in any project is knowing where you are in a project, and what changes can be made when. We will talk about strategies for breaking projects into chunks and phases, how to set criteria and decision points for each phase, using checklists and sign-offs to manage input, and recovery strategies for when your carefully laid plans go awry.

=== Session Notes ===

Notetaker: Ben

* Go round of people, saying goals
** Getter estimating how long projects take
** Software dev estimation - why does the last 10% take 90%
** Good at the known - how to estimate the unknown?
** When is the project closed?
** Pitfalls of time estimation
** Hard communicating projects to client 
** How to communicate our process to clients
** How to reality check vendor timelines
** How do you know where you are at in terms of estimated time
** When you have gone over time, how do you manage that with clients and workers
* Main things
** Tools
*** Favorite tool: the checklist
** Tactics
*** Client sign-offs
*** Narrowing the cone of uncertainty
** Principles
*** Biggest thing: chunking things up to constrain uncertainty -- going over a week on a one-week chunk is not a huge deal, going for 2 months and realizing you're half-way done, is a huge problem
* What are some other ways to approach things?
** As a client with consultants, I give them a drop dead deadline, and work with her programmer to create a timeline, set a fixed budget
** Checkpoint at 80% of project budget
* Never offer a fixed bid on an 8 month development project
* Definitely have a project manager who is staying on top of the status of the project
* New technology is both new technology, but it's also technology you haven't implemented before
* Used an excel spreadsheet do detailed estimate of programmer time, multiplying development time by 3 for ones we haven't done. we lived in the spreadsheet for 3 weeks
* Where we got burnt was value-engineering a budget and project, and we ultimately decided to eat that time. in the future we would ask that consulting time is paid for.
* We want to avoid that feeling that we "just have to get through this" and don't have any time.
* This is really when we're doing something new and different, not regular rollouts
* Use the budget to get client to understand the trade-offs of this feature over that
* We did check against the spreadsheet estimates
* We were very honest with the client about what is possible and owning risks jointly with your client
* Front-load the scary stuff
* Estimate vs actual:
** We export the excel estimate to a CSV, import to salesforce, and map our time-logging to it so we can get really granular -- down to the requirement level.
* Time-logging is mapped through salesforce to the original spreadsheet
* Transparency: it's important to really work together on the checklist, and be sure we really have a complete picture of the project to be sure things don't crop up.
* We chunked things in a way that was completely counter to how the project actually played out on a technical infrastructure level.
* Checklists, should they be provided by programmer or client?
** It's always a negotiation between all parties that have a stake in the work
** There are business milestones, technical milestones, etc.
** It's important to make clear who is responsible for what
* Don't be afraid to advocate for your needs, and to define the project process
* Let's reexamine a project and the pathologies happening
** Why didn't the ui get detailed sooner?
** There was a conflict between what the developers thought the process should be and what would have made more sense for the client and in terms of managing risks
* How much detail do you manage with a project that is already underway?
** If it's already going, at least getting a clear idea of the outcome would be helpful
* What does a client want to know?
** Always over-estimate especially for time
** Want to know the moment there is discomfort in the relationship and the developers are feeling like they can't make it
** Create a place where developers can speak up comfortably
* Estimation
** When a developer says it will take 3 hours, you have to add project management, design and q&a, and contingency -- basically triple it
** Stick to a methodology and evaluate based on it
* What about the situation of a client saying I want X features and X amount of money, how do you handle that? do you lower rate?
** Prioritize. the dollar excercise (divide the dollar among 20 features)
** Everybody can have sticker shock
* Value engineering
** The idea is, try to get as much bang for the buck as possible
** If the client has $60,000 and we give them an estimate for $100,000, what are the features we need to let go of
** Let's try to not do it for free, and be clear about how much the project is really worth with the client even if you do give a little and eat some hours
** Here's a summary:
*** Client: "we have $60,000"
*** Vendor: "it will cost $100,000"
*** Client: "we can't pay that"
*** Vendor: "here's a project we can do for $60,000, and here's what it can do and here's what it can't"
* Question: how many people do a project post-mortem with a client and internally
** I'm a firm believer in this
* One problem I'm dealing with with a current project is that there are so many requirements, I'm actually taking a lot of time simplifying and streamlining features. identifying and cutting those things that will blow up in your face
** Pulling back from specific features to requirements
* Let's have a conversation about meeting client's needs, and be really realistic
* Set up a parking lot, put things in the parking lot you're not going to use right away
* What is a chunk? it's the smallest bit we can show to a user: here's a thing, look!
* Setting up small successes every week
* It's also helpful to figure out what you know and what you don't know, and manage the things you don't know