Managing Small CAPEX Projects
by Emil Randa-Boldt
Summary
The classic project management methods can be scale up and down dependent of a project size and complexity. However, it is often seen that when dealing with smaller projects, that may not differentiate much for daily operation, it can be hard for the project manager (PM) to apply the standard tools for ensuring the quality of a project. What makes a project small can be defined in many ways. The conceptualizing of the small project in this article: A small project starts out in the gap between day-to-day tasks and the organizational determined projects. And the applied project management practice is determined by the responsible caseworker. To further clarify the context are the focus set on CAPEX projects.
The challenges working with small projects are found to be present in the initial phases of a project and to gain internal support/visibility in the organization. Recommendation of how deal with these challenges are divided in to three focus areas: Project owner and stakeholder engagement, Scope Definition and Communication. The content of the recommendations is based on the project management methods of PRINCE2 and PMI, where relevant points useful in context of small projects have been selected from a personal experience perspective. Also, the experiences from other project management knowledgeable persons are included in the finizaling of the recommendations.
This article is primarily addressing tht certified project manager within e.g. PRINCE2 or PMI, that looks for guidance of where to focus in the project management practice in absence of an organization generated project structure.
Introduction
When working in the industry or public sector do all projects not come in a classic scale such as building a bridge or develop a space rocket, where it is intuitive given - from all involved stakeholders - that this is a project and therefore you adapt a project management setup to solve the project. In an organization are different tasks processes on a daily basis. What often happens is that some of these tasks actually are projects. A key challenge for organizations worldwide is to balancing between; daily operation (“business as usual”-tasks) and transforming operation into projects that can develop their business in the right direction [1] (chapter 2.1). If the organizations succeed in identifying the small project hidden the day-to-day work, that may not differentiate much for daily operation, it can be hard for the project manager (PM) to apply the standard tools for ensuring the quality of a project. That is due to the time and resources allocated to run such a project are limited. The PM has to navigate in the project management jungle and chose to focus the available resources on key elements in process. This article offers some reflections and recommendation of how to handle this situation.
The problem with small projects is that they go under the radar - not only in the organizations but also in the research. Specific guidances in dealing with small projects does not exist. The amount of research done on the subject is very limited and general survey results on project have to be applied in the understanding of small projects.
To further clarify when and where this articles can be applied has the focus been set on the organizational CAPEX projects (CAPital EXpenditure). What characterize a CAPEX project is that the project owner and most stakeholders are internal in the organization. Exeampel of CAPEX projects could be to upgrade of machinery on a production line, retrofitting a crane on a cargo ship or develop a small internal IT systems.
The statements in this article are based on reflections from personal experiences working in the gap between solving business as usual tasks and projects in a technical organization, and further substantiated by different sources. The purpose of this article is to help you distinguish between a task and a project. And give a suggestion on what key elements you should focus on when dealing with a small project. The key elements are primarily based methods PRINCE2 and PMI.
What makes "small" projects
When a need occurs in an organization it will in most cases land on the upper management table. If the scope of the need has a substantial size and/or risk profile it will be send through the organization project system and a project organization will be establish to manage it. But in the daily operation around in companies it is often seen that management just want to get many of the smaller needs “fixed” and as quick as possible. Then job lands on someone desk as a day-to-day task. The problem then arises if this task is not recognized as a project – if that is the case.
But how can these tasks be evaluated and be determined to have the potential of being a project. In PRINCE2 they define a project as “A temporary organization that is created for the purpose of delivering one or more business product according to an agreed business case” [1] (chapter 2.1). From this definition none of the described tasks have the potential of being a project, due to the lack of a project organization. The PMI defines project as “…a temporary endeavor undertaken to create a unique product, service or result”. [2] (chapter 1.2). By evaluating a task if it complies with the characteristics “temporary endeavor” and “unique product, service or result” you will see that many tasks do. In addition to the PMI definition, are here some criteria that should be considered to evaluate if a job scope shall be treated as a project [3]:
- Is it a temporary endeavor.
- Is it a unique product, service or result.
- Do the scope include unfamiliar elements.
- Will it implement some sort of change.
- Will several organizations/departments/stakeholders be involved in the process.
If the conclusion of the evaluation consists elements from the above criteria than you need to put on your Project Manager hat on.
When a project has been identified as a project – what makes it a “small” project. The more traditional tools to estimate the size of a project is by looking at estimated cost and time consumption, but is relatively from branch to branch and is difficult to make some generalizing rules. Also, risk profile is a crucial factor regarding larger projects, but when dealing with small projects the risks are often very limited [3]
Cite error:
<ref>
tags exist, but no <references/>
tag was found