Project Management for small companies...

Small companies can be quickly overloaded with processes that are well meaning, but designed for large or complex projects in large organizations. The key to successful project management in small companies is to use pragmatic project management practices that are appropriate to the scale and needs of the company.

The cornerstone of large scale project management can be found in the Project Management Institute (www.pmi.org) and its compliment for software development processes, the Software Engineering Institute or SEI (www.sei.cmu.edu).

These two organizations provide the gold standard for large and or complex product development. If you have a product development organization with over 50 to 75 developers, you should consider allocating full-time staff and getting leadership team commitment to moving the organization to embrace the methods these organizations recommend. This is a great way to improve the predictability and financial return of a large organization. I will talk about PMI and SEI in a future newsletter.

Only a very small percentage of companies have product development teams of over 50 people. The trick in smaller development projects is to pick and choose from the categories outlined by these organizations and implement what pragmatically makes sense for the problem at hand.

For an example, lets take a “typical” eight person software product development team. Let’s set the skills in this team as one architect / designer / coder, two designers / senior coders, one coder, a configuration manager / system administrator, a tester, and a marketing / customer focus person.

My thoughts for starting point for the typical requirements for this team would be as follow:

Documentation:

The first requirement is a description of the deliverable detailed enough to obtain buy-in with the stakeholders. Second requirement is a design document that outlines the basic architecture of the product is needed. This is most likely a collection of diagrams. Additional documentation and clarification is likely to come from the user documentation and notes from testing.

Configuration management:

Software must have copies stored in safe locations (including an off-site copy). For small projects a protocol of primary, backup, and historical directories can be used, but within a few months of the start of the program, a configuration management software tool should be deployed.

Project status:

Two items here, a simple plan and a bug list. The simple plan can be as little as a set of 5 to 20 milestones for the next week through 60 days. If the project is longer than 30 to 60 days or has more than 30 to 50 development tasks, it should be documented in a pert chart or some other form. For a project of over 60 to 90 days or 75 development tasks, Microsoft Project should be deployed with one person on the team being responsible for building the plan and keeping it current.

The bug list must be a single shared project-wide list of all of the open issues in the project. For a project of this size, in addition to software bugs, it should also include requirements issues, testing issues, project unknowns or risks, and anything else that needs to be completed before the project is done. The list can be a shared MS Word document or MS Access database. I generally recommend that the tester be the only person with the ability to close or delete issues from the list.

The bug list and project milestones should be updated and reviewed every few days mid-project and daily as the project is coming to a close.

Customer input:

The best choice is always to have customers continuously involved in the development. The role of the marketing person is to facilitate that interaction. The key attribute of the marketing person is that they must be able to judge the conviction / importance of any input that comes in from any source and to then discount the inputs that are of lesser importance.

 Testing:

I believe that a full time testing person is critical even for a team of this size. It is best if they are on board from the beginning of the program. The shortest cycle-time and best quality programs that I have led have had the test team in place at the start of the program.

Cautions: