Project Development Plans

[Tom]

Ok so, more of my n00bness showing through. I've got a Development Plan to put together, and I'm wondering what you all think is supposed to be in one. I have a vague idea so far, but it doesn't really seem like enough, I dunno. I'm doing some research as we speak, but I wanted to hear from you guys as well.

[Mr. Analog]

The key to project planning is understanding what's in scope, what's not in scope and everything that you are dependent on AND things that are dependent on you.

Start shotgunning questions, find out what you already know, what you need to know and what you don't know, make sure the considerations that matter are written in black and white on paper, never assume anything. What licensing is going to be required, how does it get installed, what are the development environment needs, what does the production environment look like, how will things get logged...

Basically all these things that float around that support a piece of software have to be thought about, EVEN if these things aren't in your hands like environment or source control it all needs to be documented somewhere so when you (or someone else) picks this up 5 years from now and wonder why you have 5 servers instead of 8 you'll remember

I used to write a lot of RFQs and the main thing people cared about were what the goals were, an estimate of time and effort, how many people were needed, what the rate was, external dependencies, project requirements and assumptions. Usually there'd be a bit of back and forth between myself and the client to feel out these things and then when both sides were happy with what was written down we'd sign that bitch and start work.

[Tom]

The key to project planning is understanding what's in scope, what's not in scope and everything that you are dependent on AND things that are dependent on you.

Start shotgunning questions, find out what you already know, what you need to know and what you don't know, make sure the considerations that matter are written in black and white on paper, never assume anything. What licensing is going to be required, how does it get installed, what are the development environment needs, what does the production environment look like, how will things get logged...

Basically all these things that float around that support a piece of software have to be thought about, EVEN if these things aren't in your hands like environment or source control it all needs to be documented somewhere so when you (or someone else) picks this up 5 years from now and wonder why you have 5 servers instead of 8 you'll remember

I used to write a lot of RFQs and the main thing people cared about were what the goals were, an estimate of time and effort, how many people were needed, what the rate was, external dependencies, project requirements and assumptions. Usually there'd be a bit of back and forth between myself and the client to feel out these things and then when both sides were happy with what was written down we'd sign that bitch and start work.

Cool. Thanks Going to be fun to guestimate the time, I always struggle with that. Tend to underestimate, which sometimes leads to gross over correction :-x

My situation is a bit odd though. I have no direct contact to the actual client. Right now all I have is a "wireframe" for the project. It is fairly complete so far though. Some details are completely missing, and there's no timeframe for when even my boss's will have that information. Technically the project hasn't even been signed off on yet at all (and this client doesn't want /any/ work to happen before they sign off on it).

Right now I'm working through the wireframe, detailing the steps and requirements in long(er) form. From that I should be able to guestimate some time estimates.

Also, I'm apparently doing the plan so it can be used by both versions of the project (iOS && Android), while I'm only actually going to be doing the Android version. So its kind of an interesting task. Has to be in depth enough to cover important details, yet general enough to make sense for multiple platforms.

[Thorin]

Any idea what they mean by the words "Development Plan"?  Do they have a sample to work off of?  I ask because if you write something with lots of detail and they're looking for an overview, or you write an overview and they want all kinds of details, or you estimate nothing because you don't know enough yet and they want a complete estimate for all work (most likely scenario), well, then your doc won't match expectations.

Possible:
- an overview with a long term roadmap that lays out generally what big pieces will be done at what stage (NO DATES NO TIME ESTIMATES because you don't know enough yet)
- a detailed task list that lays out all the little pieces and estimates every single one of them (REQUIRES LOTS AND LOTS OF QUESTIONS because otherwise you _will_ find out that you forgot some major thing
- a hybrid overview with the first big piece broken down into a detailed task list

As Mr. A said, you need to ask lots.  If at any point you find yourself thinking, "Yeah, they'll probably have this on server XYZ with software ABC", STOP and confirm that thought by asking specifically what server / what software.  NO ASSUMPTIONS, everything written (even if in point-form) in a doc.

[Tom]

Any idea what they mean by the words "Development Plan"?  Do they have a sample to work off of?  I ask because if you write something with lots of detail and they're looking for an overview, or you write an overview and they want all kinds of details, or you estimate nothing because you don't know enough yet and they want a complete estimate for all work (most likely scenario), well, then your doc won't match expectations.

Possible:
- an overview with a long term roadmap that lays out generally what big pieces will be done at what stage (NO DATES NO TIME ESTIMATES because you don't know enough yet)
- a detailed task list that lays out all the little pieces and estimates every single one of them (REQUIRES LOTS AND LOTS OF QUESTIONS because otherwise you _will_ find out that you forgot some major thing
- a hybrid overview with the first big piece broken down into a detailed task list

As Mr. A said, you need to ask lots.  If at any point you find yourself thinking, "Yeah, they'll probably have this on server XYZ with software ABC", STOP and confirm that thought by asking specifically what server / what software.  NO ASSUMPTIONS, everything written (even if in point-form) in a doc.

Hm, yeah. I'll probably send an initial version of it tomorrow, after I finish going through the major points.

He (the boss) did mention he wanted time estimates, but I really can't do anything better than a very rough guess. Most of it is pretty simple and shouldn't take very long at all, but life is never that simple

[Thorin]

They always want to know how long it'll take.  And we can never really tell them.  It's not like we're building the same cinder block wall we've built a thousand times already (or else you're doing software development wrong).

[Mr. Analog]

I think time estimates are fine, but when things come up that are going to impact delivery you need to balls up and just come forward, do a formal scope change and ensure it's documented with the project materials.

@%&# that causes scope change:
-External Dependencies interfering (material, manpower, act of god, whatever)
-Underestimation of complexity
-Client adds new @%&#

The last two are the biggest ones AND the toughest ones to come back to the client with, BUT YOU HAVE TO DO IT.

If you set out to build something and realize it's a much bigger task man up and talk to the client about it PRONTO, something was missed, but that's life (and also why numbers are called estimates and not actuals).

If the client comes up with some great ideas that they want that aren't covered in the project plan, bring it out, ask him where it should fit in the current plan and come back with a new estimate (draft up an actual Change Request, it's sort of like a proposal but smaller, just entailing the change). Once he reviews it you guys will probably go back and forth on a few details before signing it off.

Once you get sign off work like it was always part of the plan.

The trickiest bit is to be friendly but firm, I've heard some wonderful and convincing words that have persuaded me into working for free and putting all the stress on myself and well, that dog don't hunt (either that or reality will come crushing home and bad decisions get made faster than good ones).

OoooOoooOooo!