Managing Small It Projects

Managing Small IT Projects Bruno Collet, MBA Independent Management Consultant www.brunocollet.com September 28, 2008

______________________

There's a myth that small projects are easier to manage than large ones. The truth is that small projects come with unique challenges that make "full-scale" methodologies such as PMBOK, IBM RUP, or Prince2 ineffective. Consider the following: for some reason there is a 1-day (we are always talking in "effort" days) lag on a 1000 days project, and the same 1-day lag on a small 50 days project. The large project may incur a time/cost increase of 0.1%, whereas the small project suffers an increase of 2%. It is very easy to blow small projects because they are fast-paced. The challenges in managing small projects come from tight planning and responsiveness. On the other hand, the challenges in managing larger projects consist more in analyzing complexity for business areas, technology, risks, and managing a large number of stakeholders. To make matters worse, because of the belief that small projects are easier to manage, we tend to assign inexperienced project teams to these small projects. Although everyone admits that small projects require a different approach than larger ones, there is a heated debate about what this approach should be. One of the big questions is: should we scale down full-scale processes for small projects, or use Agile processes? Proponents of Agile also argue that we should scale up Agile processes for larger projects. In this short investigation we'll address the major considerations for effective management of small IT projects.

What is a small project? It is unnecessary to agree on a strict definition. In her book Project Management for Small Projects, Sandra Rowe lists some typical characteristics of small projects, which Bill Brantley repeats in this article.

Managing Small IT Projects Bruno Collet, MBA, Independent Management Consultant www.brunocollet.com

1

PMO approach Managing each small project independently in a traditional way will create a management overhead and will neglect the dependencies between the small projects. Relying on a project management office (PMO) will help considerably, by: •

Leveraging the repetitive nature of projects: When an organization has small projects, they come usually in large numbers and share many similarities in terms of type (example: web), technologies, and overall development lifecycle.

•

Helping allocate shared resources among small projects: Small projects often share resources such as developers for example. Therefore, they intrinsically depend on each other; a change that affects the plan of one project will likely affect other projects. As a consequence, the PMO has to manage a central planning and allocation of resources comprising all small projects to reflect this reality.

Initiating the project Initiating activities are the most critical ones for the project success. They will ensure that we do the right things and will establish a basis for doing things right, both being the two sides of that same coin named "client satisfaction". For small projects, we have to strive for an initiating approach that is at the same time minimal and complete. We also need to distinguish what is internal from what is external. Indeed, communication with the client (external) must be strictly relevant and expressed in client terminology. We start the project by defining the following items: • • • • • •

Vision or business case Scope: features, system boundaries, explicit exclusions, data transfer, interfaces with other systems, user documentation, user training, etc. Milestones and associated deliverables Risks Team Stakeholders

This is an internal document that is usually called project charter. A one-pager version is communicated to the client. It summarizes project charter and emphasizes one additional section: the client communication plan (CCP). The CCP's importance stems from the fact that lack of client responsiveness often hinders small projects. The CCP defines the client touch points in time, person, and expected result. For example, the approval of a milestone occurs at a predefined date, is done by a predefined person, and has the predefined consequences (starting the next iteration,

Managing Small IT Projects Bruno Collet, MBA, Independent Management Consultant www.brunocollet.com

2

billing, etc.). The client, and every stakeholder for that matter, has to feel that we are driving on a well-lit road with clear road signs. Note that a precondition for being strict with client interactions is that we ourselves have to be rigorous with the project. You cannot expect the client to behave well if the project is consistently late or if the deliverables are of poor quality!

Planning and monitoring the project I recommend Scrum-like project management after completing the initiating activities. It means that: •

The project is divided into short iterations of the same length (for example, 1 week). Each iteration ends with a demo and a delivery. The delivery can be either internal or external (if it hits a milestone for example).

•

Only the current iteration is planned in detail. The overall planning, however, still has to comply with the milestones described in the project charter.

•

The team meets every day for a time-boxed meeting of 15 minutes. The goal of the meeting is to ensure team communication, to track progress and to remove impediments. Changes are also addressed in this meeting.

•

Quality is a pervasive concern. Each feature (or use-case, or user-story, whatever the name is) has an associated demo that includes live test scenarios. The feature is "completed" when it passes this demo.

Closing the project Project closure often eludes project managers. How often we found ourselves spending time on a project that was supposed to be finished weeks ago? It is critical to transition clearly from development to maintenance, i.e. from project mode to operations mode, and it requires client agreement. Approval of the final release should be, as the name implies, final. The client often sees this last meeting as just another meeting and fails to understand its true meaning. It is the project manager's responsibility to make this meaning clear, even if it triggers client concerns or, as it is usually the case, extra validation test. It is better to delay the project completion that to believe it is finished when the client thinks it's not.

Tools I'm always baffled by project managers using tools far too complicated for the task at hand. The tools we rely on should really be as simple as possible. Many project managers sneer at Excel, ordinary documents, or simple wikis as project management tools, but these tools actually do the job, at least for small projects. So why buy, install and learn to use elaborate tools? Whiteboard, paper board, index cards, Excel, wiki, formatted email. Period. Managing Small IT Projects Bruno Collet, MBA, Independent Management Consultant www.brunocollet.com

3

References Implementing Project Management Best Practices on Small Projects, by Simon Buehring, from ComputerWorld UK, 2007: http://www.computerworlduk.com/management/it-business/it-organisation/instantexpert/index.cfm?articleid=339 Choosing Just the Right Level of Project Management for Small Projects, by Thorn and Dixon, George Washington University: http://mdm.gwu.edu/Forman/GSmodels/LevelsofProject%20Management.pdf "Project Management for Small Projects" Review, by Bill Brantley, from Eclectic Bill blog, 2007: http://eclecticbill.blogspot.com/2007/09/project-management-for-smallprojects.html Managing Small Projects in your Project Management Life Cycle, from Method 123, 2007: http://www.method123.com/articles/2007/09/21/Small-Projects/ Project Management Office (PMO), Wikipedia: http://en.wikipedia.org/wiki/Project_management_office Project charter, Wikipedia: http://en.wikipedia.org/wiki/Project_charter Project scope, Wikipedia: http://en.wikipedia.org/wiki/Scope_(project_management) Business case, Wikipedia: http://en.wikipedia.org/wiki/Business_case Milestone, Wikipedia: http://en.wikipedia.org/wiki/Milestone_(project_management) Wiki, Wikipedia: http://en.wikipedia.org/wiki/Wiki Scrum, Wikipedia: http://en.wikipedia.org/wiki/Scrum_(development) Agile software development, Wikipedia: http://en.wikipedia.org/wiki/Agile_software_development

Managing Small IT Projects Bruno Collet, MBA, Independent Management Consultant www.brunocollet.com

4