There are lots of small / mid sized software companies and there are lot of small / mid sized projects in this world.

The project management techniques we read in books are best suited for bigger projects. As we can not spend much time in PM related stuff that much, what technique best suits small / mid sized projects and takes less time for management. (Risk management part can be tolerated)

  • Maybe this question would give the expected insights? pm.stackexchange.com/questions/195/…
    – Tiago Cardoso
    Jun 15, 2012 at 12:42
  • Besides, have you had a look at Agile / Scrum? It may fit your needs as well. If not, I'd say your question could be improved. pm.stackexchange.com/questions/389/…
    – Tiago Cardoso
    Jun 15, 2012 at 12:44
  • Who said anything about doing 'em all? You should be able to pick and choose what works best for your situation. There is NO one size fits all. You may want to look at Mike Cohn's Agile Estimating and Planning (it talks about how planning an estimation itself can be agile and lightweight)
    – PhD
    Jun 16, 2012 at 3:37
  • OK. I'll take a deep look in to Agile way
    – Imdad
    Jun 16, 2012 at 6:11
  • @Imdad, don't do that. A deep look into an Agile way will narrow down your view, and will give the false pretense that it solves all the problems. First, find out what you really need and then make a deep dive into a methodology.
    – Zsolt
    Jun 20, 2012 at 14:35

3 Answers 3


"The project management techniques we read in books [sic] are best suited for bigger projects." I think you made an erroneous conclusion here. The PM techniques are size and industry agnostic. What you seem to be missing is the tailoring of these techniques to fit the project and the environment in which you are working. What might change with size is the formality with which you would implement a PM capability, or perhaps the rigor. But the PM work is still performed. For a large project, I may develop a Project Management Plan and subordinate PMPs with over 200 pages. For a small project, the plan might be resident in my head. But in both cases, I planned my work. For a large project, I may deploy an ANSI compliant EVMS capability. For something small, I may use MS Project and an excel sheet to do the same thing.

The techniques and methods are scalable and tailorable. You need to do both always.


All successful projects comply with a relatively short list of principles/themes:

  1. Does the project make sense from a business point of view? If no then the project should be terminated.
  2. Are team roles and responsibilities clearly defined? If no then confusion will ensue.
  3. Are plans in place that are feasible, achievable and realistic? If no then expect stakeholders to be annoyed and the team to be frustrated.
  4. Are plans, risks and issues reviewed regularly in a controlled manner? If no then expect to be putting out fires because of issues you didn't see coming.
  5. Is the team clear on what the end goal/product of the project has to look like? If no then expect scope creep and dissatisfaction with the end result.
  6. Does the team apply lessons learned from this and other projects? If no then expect wasted effort as you reinvent the wheel.
  7. Is there open, proactive communication between the stakeholders, PM and project team members? If no then expect differences in assumptions, delays, rework and added costs.

In terms of the details of tools, techniques, methods, processes, etc in order to implement these principles and themes see David's excellent answer.


Project management really boils down to a few simple concepts.

Decide what needs to be done (scope). How much do we have to spend (cost). When does it have to be done by (schedule).

Anything beyond this is defined by your individual project.

Estimating, risk management, change control; all of it is dependent on your situation. Short term project where you control most of the input? Probably not a lot of risk or risk management to worry about. History of similar projects? Estimating (both cost and task duration) is probably going to be straightforward. Requirements and/or scope fairly well defined, or limited number of stakeholders? Change control will be pretty easy.

It's as each of these factors increases in complexity that you have to start getting more in-depth in terms of processes. But at the base level, if you have a way to track tasks, cost, and schedule, that's all you need.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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