When projects go bad: How to transition from a bad developer? 3

[newyorkny]

Hello, Tippers:

I'm being asked to help in a situation where a developer has apparently been working on an important project for a year and hasn't been able to get the product in a commercially usable form.

We've all been called upon to resurrect a software project, I'm sure. This question is about what we need to get from a developer to help ensure a smooth transition.

I think:

1) codebase
2) ERD
3) logins and passwords
4) any user documentation s/he has created or is in possession of
5) ????

Please help me brainstorm this list.

Many thanks,

NY

 

[johnherman]

Some of these may be out of scope relative to the developer, but: requirements, specifications, statements of work, architecture and design diagrams, sizing and capacity planning, performance considerations, test data, load testing, unit and functional test plans, integration testing considerations, implementation considerations

-------------------------
The trouble with doing something right the first time is that nobody appreciates how difficult it was - Steven Wright

 

[newyorkny]

John,

I think those are a great start. I will definitely need to see if the mis-performing programmer has those documents.

NY

 

[PDQBach]

Change list (definitely a change list) and issues list. The issues list could be particularly instructive since it could very well point to the reasons why the project has stalled.

My experience suggests that the issue rarely lies with a "mis-performing programmer" but, rather, with the overall structure and environment that he/she was working in/on. How, for example, can a single-programmer project be a year down the road and not have it ready? It seems to me (from a Project Management perspective) that someone hasn't been doing the work he (or she) should be doing (and that "someone" isn't the programmer).

 

[newyorkny]

PDQ,

That is certainly a possibility (that the project was mis-managed). This effort has not been professionally project-managed to date. I suspect that the developer has some valid complaints concerning the direction he has received. The technical acumen and approach of the owners of the software has not, so far, struck me as sophisticated (but they freely acknowledged that, so that's a terrific plus in my book).

I have not been commissioned to weigh the merits of the developer nor assess his complaints, although I will definitely review the requirements documents and other guidance he was given in an effort to avoid re-creating the quagmire.

I can refer to him as the "allegedly mis-performing programmer." But the fact is that the two sides have irremediably fallen out, and I concur in the owners' assessment that fresh blood is the only way to resurrect this. I am encouraging the owners to build the new statement of work with the new guy/gal so that it has regular milestones. They insist on a flat-fee arrangement, which is theoretically sound, but which can leave a developer feeling unincentivized if not structured properly.

Thanks for your thoughts.

NY

 

[JimmyTheFish]

In addition to the comments you've received, I would be very wary of a client who wants a flat-fee arrangement and ensure you have a fully agreed statement of work. Not knowing any details of what has gone on, it is quite possible that the 'underperforming developer' was incorporating change requests without acknowledging this to the PM. It is well worth identifying whether this was the case and taking steps to ensure the scope is well understood, documented and, most importantly, agreed & signed off. Subsequent change is then more easily managed. Alternatively, before taking on fixed price work, ensure you have a statement of any assumptions you have made associated to the fixed cost work.

 

[stevepm]

Some of these may be out of scope relative to the developer, but: requirements, specifications, statements of work, architecture and design diagrams, sizing and capacity planning, performance considerations, test data, load testing, unit and functional test plans, integration testing considerations, implementation considerations"

I couldn't have said it any better myself. Follow these tips, and you may have some chance to right the ship.

Regards,

Steve Mark

How I Pass the PMP Exam for the PMP Certifiaction

http://www.pmguide.net/Recommended/F1/PMPrepcast.php