How to show planned project approach to the client?

Question

I've came to a situation where the client asks me the next two things:

1. Give me your project plan of how you would approach this project to make sure I have a result at the end of a specific month.

2. Elaborate how you would analyze the existing code for the front-end and the back-end to make sure you understand what the previous programmers have done.

This is from a freelance perspective where I "act" both as a PM and as a programmer.

What kind of answer should I provide to the client? We are at the phase where he is interested in my services and wants to know how would I do it.

Answer 1

You have two methods you need to disclose to your potential client: 1) PM, 2) Software, SDLC. These two methods are separate but need to work collaboratively.

I'll answer to #1 and leave #2 to the more technical folks on this exchange.

Your client is looking for how you scoped the project in terms of what is it you will deliver at the end of the project as well as interim deliveries during the project. This is best exhibited as a project scope statement, often found in a project charter but also within your Project Management Plan (PMP) as well as an initial Work Breakdown Structure (WBS) and possibly an initial WBS Dictionary. This is the what.

Your client will want to see how you are scheduling the work, the phases you are proposing, the amount of time you will need to make the deliveries. This is best displayed as a high level schedule with milestones, such as a Gantt chart, but your client may want to see your preliminary schedule showing your WBS loaded across time. This is the when.

Your client will want to see the cost of the project. This is best delivered as your cost proposal with price but your client may also want to see how much components of the project cost, which is exhibited as part of the Performance Measurement Baseline (PMB) and within your WBS Dictionary. This depends, however, on your type of contract with your client.

Finally, within your PMP, your client will be interested in your management approach to manage and control the project, covering such topics as risk, quality, communications to stakeholders, your procurement approach for materials you are going to need, etc.

This is a lot of information you likely don't have all sorted out yet since you do not even have the job. So scale this information accordingly, i.e., show what you have at a high level, more strategic kind of view. You will likely not have hard core plans and schedules to show at this stage so you will want to deliver this information more in a presentation format. The communication message is that you know how to organize, execute, manage and control work to get to the finish as efficiently as possible and to be able to communicate early and often when things go south.

Answer 2

A technical perspective:

From the information you have provided I infer that the client is technically competent and understands the risks of transferring a code base to a different programmer very well. It is a frequent problem that programmers underestimate the effort to dive into an existing code base.

From my point of view it will be important to demonstrate that you don't.

Factors influencing effort to take over an existing code base

Depending on the size of the code base it will be very hard to provide a reasonable estimate, because the following factors can heavily influence the required effort:

• Size - rough metrics such as files, lines of code
• Technological basis: Is it based on a well known framework, one you might even now? In my opinion this would immensely increase the trust in your capability.
• Documentation, comments in code: Do those exist and were they maintained?
• Capability of the previous programmers and reason why they abandoned the project.
• Age of software: From experience I would say the older the code base gets it becomes more and more probable that you will find hacks and shortcuts unless the development was very disciplined and refactored code from time to time.
• External depencies (libraries): Are they mature and stable, manageable? Or were some obscure pre-release libraries used.
• Lots of custom meta programming and "ruby magic" as frequently seen in rails projects can be very problematic when trying to understand the internals
• Test-Coverage

I would advise you to elicit as much of such meta information beforehand in order to demonstrate your competence and planning your actions.

General approaches

For getting into the code, it would be ideal if you could arrange at least one review with one of the original programmers, so he can give you a high level design and explain their design decisions.

Another common approach for familiarzing oneself with a codebase is to pick a specific use case and debugging through it from the top to the bottom.

Depending on the size of the code base you might consider using specialized tools for visualizing object dependencies, analyzing code quality and the like.