Red Warrior's Journal: PM in the AM, ask the cool kids

BLUF[6]: What artifacts should one develop for a small, "rush" project of 3-4 months duration. I want enough for clear direction and historical documentation, but no more than absolutely necessary.

----
The long version:

That Maven of Management Helicobacter, the Stalwart Degrees, the Esteemed Mr. Lindenmuth, and the cast of thousands who read this journal and have some experience in project management and/or being a lead devolper on a project, lend me your ears.

Well, actually, I have no use for your ears. What I'm hoping for is your thoughts.
So....

This project that I am in charge of is expected to kick off on Wednesday. I am doubtful that it will happen that quickly, but it might. There will be a couple days of overhead in getting the contractors' workstations set up (mostly the dev environment, as setting up for this monster [at least by our agency's standards] application requires a bit of hand-crufting the first time), introductions to stakeholders, etc, blah.

Other background stuff, I am going to my "overnight wonder" PM class on the 12th and 13th. There is a fairly important meeting on the agency-wide project[1] on the 12th, particularly on the mainframe side. My nominal lead will go in my stead to that meeting. If the contractors are here by that date (which I expect), I will have them go as well.

Oh, and I will be in Dallas for the military on the 12-14th of Jan, and teaching a class for the military Feb 5-17. I will have the ability the check email a couple times a day during that timeframe.

There are also some features being added to the applicaiton by another project (actually, the same project which spawned my app. It's long-term goal is to take all the disparate systems we use to conduct our core business and turn them into a coherent suite of applications) which I will need to coordinate with. Mainly in the area of keeping the branches from getting tangled. THEY have a later implementation date. We just need to manage not to step on each other's toes.

I'll have two contractors working for me, one for mainframe/messaging, one for dotNet stuff. They have both worked on projects for the agency for a number of years and know our systems, our data, and our culture. Thank [diety_of_choice] for LARGE favors. That really makes my job easier. Though not this particular application. As the work is being done to my, I can jump in on the dotNet (but not the mainframe&messaging) side in a pinch. However, I want to avoid that, as I have strong feelings about project managers programming. The phrase "Know your role..." comes to mind.

blah, blah, blah, blah.
-------

We have up to[2] 730 hours worth of work, divided into about 600 hours of development-related tasks, and about 130 "other" (documentation, user testing, planning, project management, overhead, etc.).

• May 23 is our "hard" date. 'Cuz the feds tells us so.
• March 3+/- is our soft date. There WILL be a production drop on that date, with what is tested and working at that point[3]. This also the date we will integrate the our new shared security client with our app.
• Feb 15 is our (tentative move to pre-prod and business area beta testing date. (and yes, I can translate hours to weeks...). I won't be on site on that day. :-(
• Dec 11 is the latest date the contractors will hit the ground. It is also the date by which their workstations and development environments will be up and working. AKA "start date".
• Dec 6 is the earliest date the contractors will hit the ground. The workstations may or may not be configured by this date.

That is the rough schedule I have to date. AND I know I will be gone on the 12th & 13th, so I need some plan that is not crap before the 6th, so that I don't waste their time and start out with the project behind.

What I KNOW I will be creating in the realm of artifacts ARE:

• A Project plan/Gannt chart. Which, sadly, means I will need to learn to US MS Project[4]
• A detailed breakdown of tasks (we have a high level one now, that guestimates in about 5 hour increments)
• An Implementation Plan. (I'm actually quite good that these) Probably a second one, depending on whether I think we can get everything into the March 3 drop.
• A Communication Plan. This will actually be incorporated into the Implementation Plan.
• A weekly status reporting/progress tracking document format of some sort that links the detailed task listing to project completion.

What other documents do you think would either be necessary or REALLY helpful? I will need some sort of format that documents what changes were made within the application & mainframe procedures, as I will need to update the application's documentation[5] after completion of this project.

Also, as a confirmed meeting-hater, I am mulling whether or not to have regular status reporting/review meetings and at what frequency. I am leaning towards "no" and "never", as I expect to be talking informally on a daily basis with these guys, and don't like meetings for meetings sake myself. I will be updating MY boss on a weekly basis, but I am thinking that informal communications as well as the weekly progress tracking document should give me adequate prep. OTOH, You've just GOTTA have meetings! Didn't you read the memo?!? Thoughts?

[1] The mainframe portion has been going on for quite a while (almost 2 years) is almost completed, which is what the meeting on the 12th is to go over thier implimentation and a final check for any gaps.

[2] The business area, naturally, has not given us any actual requirements to date. Meeting on Thursday to 'splain to them what happens if they don't. Short answer, is we assume worst (most work for us) case, which is where we get the 730 hours from. I'm thinking that we will end up somewhere in the vicinity of 550, as there is really no business reason to make all the presentation/interface changes we've outlined. Also, the 730 has about 15% padding built in. At least, we THOUGHT it was padding when we wrote it up.

[3] Our 730 includes about 150 hours of mainframy/messaging (IBM Websphere) type stuff. That, and a couple of transaction pieces (150-200 hours, IIRC) are the critical parts. All the rest are really presentation stuff.

[4] Yes, I know. However, in my agency, Projects use Project(tm). I can do it in some other format TOO, if I want. :-)

[5] Which is excellent, up to date, and relevant. The project (the app moved out of development and into maintenace about six months ago) had an honest to goodness business analyst/documentation position. Which was filled by somebody who is competent. It is a thing of beauty. Usefull documentation!! And as the maintenance guy for the application, I have every intention of keeping it so. However, there is a LOT of it that will need to be slogged through, and I do NOT want documentation updates to impact on our timeline. I just need enough bread crumbs so that I can get it done at a later date.

[6] Bottom Line Up Front. "Read this bit to see if you care or need to read the rest" :-)

Hmm. May 23?

[RevMike]

NPI?

Re:

[Red Warrior]

Yup.

Deliverables

[helicobacter]

This is my "usual" documentation list for any type of project. If you don't know what any of them are, just let me know and I will elaborate. I put * next to the ones I use most often. If the project is short, some of the docs end up being incorporated into other documents.

It sounds like the requirements are coming from elsewhere, otherwise I would add Business Requirements and Functional Requirements to this list. If you're lucky, other people create these, but I have had to do both for projects in the

Reports

[Talinom]

Don't forget your TPS Cover Sheet [chrisglass.com].

Oh, and my advice is to just wing it. Yeah, just tell everyone what needs to get done on an informal basis so they don't have any stress and let them do their thing.

I mean, how bad can it really get?

Less artifacts, more code

[TheConfusedOne]

Sounds like your start date and your disappearance are way too close together.

At best I'd say get a 2 week contingency plan in place to assess the current code and the mainframe stuff you're waiting on. If there's some upfront work that can be done to simulate any missing pieces from the mainframe they can get working on that. Beyond that, I wouldn't get too uptight about all the documentation until you're actually working and know that all the pieces are in place or exactly what's missing.

As you know all

Reporting for duty - though I'm better at KP ;-)

[Degrees]

I've done a lot with Gantt charts and MS Project work, but always as the worker bee, not the manager. The comments above look fine to me.

Once you get the project kickoff meeting out of the way; for weekly meeting, I'd try to keep it to 10 - 15 minutes, with a specific agenda - no bunny holes! Take the weekly milestone list suggested by Heliobactor, and ask only two individual questions of each team member: 1) Did we make last week's milestone? 2) Is there anything in the way to prevent you from hitting nex

Re:Reporting for duty - though I'm better at KP ;-

[helicobacter]

And all plans change throughout the process.

I think everyone had very good points here -- it is often the struggle of the PM to not let the process get in the way of getting the actual work done.

Try all kinds of different approaches and be flexible to change and abandon those that are not working for you.

Re:

[Degrees]

Not related to Project Management, just regular old Management, I read an interview Esther Dyson did with Eric Schmidt. Turns out one of his secrets for high worker productivity is to have each manager have 40 - 50 direct reports. With so many people under them, each manager is so busy with administrivia that he/she doesn't have time to derail the employee from the project they are working on.... ;-)

Put another way: straight from the Dilbert blog [typepad.com] "Leadership is a form of evil. No one needs to lead you to d