Rebecca has posted 11 posts at DZone. You can read more from them at their website. View Full User Profile

Lessons Learned from Taking On a Project in Crisis

04.04.2010
| 5380 views |
  • submit to reddit
I just got done with an emergency project for an agency developing a public-facing application for a mutinational technology client you've most certainly heard of. I developed the entire front-end -- HTML, CSS, and JavaScript -- for a non-trivial application with a limited spec in just seven days. The experience was so eye-opening that I feel the need to write down some of the things I've learned, in hopes that I can benefit from my experience in the future.
  • Demand all technical source material up front, such as functional specs, mockups, work that's been done to date, etc. Give the client a fixed amount of time to deliver that source material, and don't make a decision about taking on the project until you've seen it. What the client can deliver in that fixed amount of time will shed a lot of light on the state of the project and whether their expectations are realistic.
  • Set clear time expectations. Am I willing to work 16 hours a day? Am I expected to? Are there hours during which I'll be expected to be available? Am I willing to work on the weekend?
  • Find out whether the client expects me to be available after the imminent deadline, and to what extent. The last thing I want is to snatch defeat from the jaws of victory by being unable to support the code I've written.
  • Do not accept responsibility for commitments made on my behalf. The recruiter said I'd be available six hours a day when I told him four? Not my problem. The client committed to having a feature ready for review without consulting me? They probably won't make that mistake again.
  • Ascertain the rest of the team's commitment to the project. If I'm expected to work long hours, will they be there during those long hours to get me what I need? Are there any constraints on their availability?
  • Establish a single point of contact at the client, and make clear I'll be depending on them to get me any information I need and I'll be treating their decisions as final. Insist that they participate in all calls I'm expected to participate in.
  • Limit the amount of work I do before I have access to all client systems I'll need access to: version control, testing environments, ticketing systems, etc.
  • Insist on a ticketing system. I'm new to the project and I have a lot to get up to speed on. I don't want emails flying at me from all directions -- decisions and technical requirements need to be documented in a single place that everyone can see. This is my only insurance when someone wants to know why something isn't done, or why it wasn't done the way they expected.
  • Insist on version control, even if it's something crappy like CVS. I'll need a way to make sure the rest of the team has access to my latest and greatest. FTP blows, especially when I'm FTPing to a server where another developer is constantly deploying a new build, overwriting my work.

What other advice do you have?

From http://blog.rebeccamurphey.com/2010/04/02/lessons-learned-from-taking-on-a-project-in-crisis/

Published at DZone with permission of its author, Rebecca Murphy.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Thomas K. replied on Mon, 2010/04/05 - 8:40am

Should be as well on the list:

  •  testing / continuos integration available (even for a "frontend only" project)
  • make sure the functional requirements explicit mention what environment should be supported (IE 6 any one? iphone is SO common it is "obvious" it has to be supported?)
  • Know all deadlines upfront, what did the agency commit to to their clients, did they include buffers? (you will know when the pressure raises upfront)
After all a helpful article, I hope many contract developers will learn from it.

Alejandro Dobniewski replied on Mon, 2010/04/05 - 6:07pm

Wait, do you mean some project are not like that? ;-)

Nice article

I agree with the previous comment. Implement your own development environment/tools if needed (version control, integration).

 

Rehman Khan replied on Sat, 2012/02/25 - 4:32am

Thanks for writing this! Seems like a great set of guidelines for jumping into a project like this, and these projects are notoriously difficult to manage - 90% of the time it seems like we just get blindsided into doing a bunch of unused work (and a lot more work than we promised to do).

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.