SMALL BUS HOME
|
Define the Work - Small Projects |
The definition of small projects covers many types of work. In most companies, these small projects are not viewed as projects at all. Your company may call these enhancements or discretionary requests. The work is unique, has a beginning and end date, results in the creation of a deliverable, etc. It’s just that the work is small and so the project itself is small.
In some organizations, small work efforts are considered a part of the support or operations organization. There are many work efforts that also fall under support because they originate with some type of problem or failure to a production process. Sometimes the failure is critical to resolve immediately, and sometimes the failure is minor and can be allowed to continue unresolved for a long time. It can be hard to decide whether a small piece of work should be managed as a support request, or managed as a small project. If a problem arises that requires a fix to be performed quickly, the work is definitely support. If a problem arises that can be prioritized and worked on sometime in the future, then it is considered a small project.
In general then, small projects can include the following.
Actual unique work efforts that are clearly projects but have a short duration and small numbers of effort hours.
Enhancements to existing production processes and systems.
Bugs and errors in production processes that are nuisances, but can be scheduled for resolution at a later time. That is, fixing the problem is a lower business priority than other work.
Small process improvements.
Discovery or fact-finding work that may lead to further Service Requests or a project.
Changes to production processes that are the result of legal, tax or auditing requirements. These requests may not be considered enhancements, since they do not provide any additional business value.
If work is classified as a discretionary small project, it does not diminish the criticality or the value of the request. It only means that there is discretion as to when the work gets done. For example, if a request is important enough, it may push to the top of the work queue and be started immediately. However, later an even more urgent request could come up that would require the other request to be put on hold. The nature of discretionary work is that it is subject to prioritization decisions. This is in contrast to true support work. If a production process is down, or is producing inaccurate results, then typically the problem needs to be resolved now, and cannot be stopped because of a discretionary request.
In general, all small discretionary work can be documented, evaluated and prioritized through a Service Request Process.
The Service Request Process
In a small project, there is usually not a lot of effort associated with formally defining the work to be done. However, some work still needs to be done. The result of this short definition is a one-to-two page document called a Service Request.
| Along with a much shorter project definition activity, the process for assigning the work is different as well. When the work definition for a larger project is completed, the project is usually ready to begin. However, for smaller efforts, there may be many more Service Requests than can actually be worked on at any given time. Therefore, a process needs to be established for gathering Service Requests and assigning them to team members based on client priorities. Since there will likely be many Service Requests, it is important to have some way to keep track of them, and a way to ensure that the higher priority requests are being worked on. The following Service Request Process can be used. |
Project manager reviews and clarifies. The project manager reviews the Service Request to ensure that the work is understood. The project manager asks questions of the client if necessary, to clarify what is being requested. The project manager must also understand the criticality of the request and whether any prerequisite work needs to be completed first.
A high-level estimate is prepared.
If the project manager understands the work well enough, and if they have the proper level of expertise, they provide a high-level estimate of the effort hours and duration and include this information on the Service Request. It is possible that once the client sees the estimated effort, they may change their mind regarding the relative priority. For instance, if the effort is much higher than they realized, the priority may be lowered. If the estimate is much smaller than they realized, they may raise the priority higher so that the work can be completed sooner.
If the project manager cannot estimate the work, they assign to a team member to create the estimates. If no one on the team has the time or expertise to create a high-level estimate, then the estimation process must itself be placed on the backlog. The client must decide if the effort required gathering information to create the estimate is of a high enough priority that they are willing to work on it rather than other Service Requests. This high-level estimate is used for prioritization purposes only. When the work is actually assigned, a more detailed estimate can be prepared, if necessary.
The request is assigned or backlogged. The project manager and client evaluate the request against the other work that is assigned and on the backlog. They also review the available capacity and skills on the team to determine if the work can be started immediately. If the required resources are not available, or if the work is of lower priority than other Service Requests, the new request is placed on a backlog list. The backlog contains all work that has been requested, estimated and prioritized, but is not assigned to begin yet.
Periodically review the backlogged work. The project manager and client review the backlog on a regular basis. When the priority of a Service Request is high enough and the right resources are available, the work can be assigned to begin. If a Service Request on the backlog is more critical than work that is in-progress, the previously assigned work is placed on-hold, put back on the backlog, or used as filler while the new request is begun.
Revalidate the initial information. When the work is assigned to begin, the person(s) doing the work should validate that the information on the Service Request is correct, and that the estimates are accurate. If they are not, then the new information should be documented and discussed immediately to see if it will have an impact on the priority. For instance, the client may want to proceed with a small project of 40 hours. However, if the more detailed estimate ends up closer to 80 hours, they may not want to perform the work at that time. There may be other requests that are more critical and take less time to complete.
Manage the work. Once the work begins, it is managed through the Manage the Work processes (Manage scope, communication, risk, etc.) Since the request is small, all of these project management processes are only utilized as needed. Project Management Procedures are not set up for individual small projects. Instead, generic procedures are established to govern all the work performed through Service Requests.
Close the work. When the work is completed, the client should signify their approval. The Service Request should then be closed and moved to a closed queue that tracks these requests for historical purposes.
