I work in a small company, we don't have clear roles and depending on the case somebody different can take the role of project manager, this is great but each one organizes the project different which can create some confusion.

I've been wondering whether it would be a good idea to create a document specifying the process required for each type of project. What is important to include in the document? How can one handle improvements and measure what works best?


What you're talking about is creating a 'methodology', and yes, it's a good idea.

The methodology is created for the reason you mentioned - so that (most) anyone can step in and keep the project moving, because it follows an established process and requirements.

As for what to include - that depends on the project type and what your company feels is important. At the very least you will probably want a project charter or scope statement (what it is we're doing, what's included, who's the client, etc.), an estimate and budget procedure (how do we develop the estimate, how do we define the budget), the processes for execution of the project, the monitoring processes, and the close out procedure.

The Monitoring process addresses the improvement and measurement aspect of your question. It's here that you'll determine what's important and needs to be monitored/evaluation, how often, what metrics, what variance tolerances are acceptable, etc.


I agree with Trevor that you are talking about establishing your methodology and that it is a good idea. Before you just in with both feet, you may want tot do a bit of review of available methodologies that are used in your field. For instance, in many construction projects, a traditional waterfall methodology with most of the artifacts discussed by Trevor and codified (sort of) in the PMI PMBOK, is the methodology used with some tailoring to suit the project size. In IT development, there is a lot of use of agile methods, e.g. Scrum, Extreme, Test Driven Development, Feature Driven Development, etc. Each project will likely have a methodology that fits it best, but you have to be sure that your company's methods policy doesn't try to fit all projects into only one method, unless all projects are the same kind. Make sure your policy calls for a method evaluation at the beginning of a project, and that you standardize enough different methods to accommodate variations in what your company does. The bottom line though is that having a standard procedure for whichever methods you choose is going to be a huge benefit int he long run, particularly if future work will ever have to look at the past.


I am part of a small app development company and we are also in the process of defining our processes and "know-how" principles.

As far as the project proposals go, we have defined a process that has resulted in landing more sales of our projects (mostly with big companies).

I can share with you some of the learnings:

  • The document is 5 pages long with the least text possible. (Think about how Twitter obligues you to write only 140 characters per tweet). We do the same with our project proposals.

  • The document's "speech" is inspired in Simon Sinek's Ted Talk about the purpose of the projects.

  • One of our greatest inspirations for defining the document is this infographic

  • One important aspect about this document is to remind that the main goal of it is to create interest in the client for a further meeting or negotation. Tough, it is important to pay attention to design, speech and the organization of your document because it generally creates a first impression.

The structure of our project proposal defines much of our operations process, for example, we structure our development process like this:

  1. What is the objective of this new project? (Why are we doing it) 1.1. What problem are we trying to solve
  2. How are we going to solve it? (Technologies, proccesses, stages, tools, methodologies)
  3. What are the short term, mid term and long term benefits of working on the solution. (Define tangible and measurable objectives)
  4. Finally, define the costs in time and money.

As an advice, do not forget to include a terms and conditions page with all the specific measures to avoid, e.g.

  • Never-ending changes to the project
  • Future feature additions without any cost
  • The client extending the project deadlines or milestones because of not providing the content or appropiate information

There is an interesting article from Jessica Hische where she talks about how she handles the project proposals for her clients.

Hope this information works for you and maybe you can add to it with your future experiences. (Sorry if I mispell something, the english language is not my first language.)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.