Abstract
Not all projects are big projects; better yet, small companies usually have very small projects. There is a general agreement on how to manage big and complex project, but what about those small ones that can make a difference? This presentation will show the general principles applied in an internet start up company to manage projects between 40 and 120 hours of work and it will also show that accepted PM principles like the ones proposed in A Guide to the Project Management Body of Knowledge (PMBOK® Guide) are a very effective tool to keep those projects under control.
A little story, Chapter 1
Warning: This is a fictional story. Any similarities to real persons, companies or projects are completely coincidental.
“Hey, Joe”, my manager said, “you are one of our best project managers and I know you have some open time in your schedule”. I sat down ready to hear his request; “Marketing just bought this nice application to keep track of its campaigns and we need somebody to look over the installation of the software. It is no big deal, It's one of those off-the-shelf applications, the installation is very straight-forward and we don't expect any issues. I'm asking for your help because the Marketing Manager is a little nervous and it will help to have some reassurance by providing him with a little support.” After a few seconds, my PM mode kicked in and I asked: “Do we have all the technical specifications for the software? Do we have the hardware? Is the application going to be available over the network or is it going to sit in somebody's desktop?” (Too many questions at once, I said to myself). My manager gave me his big smile and said, “everything is ready, don't worry, this is just a piece of cake”. I said “All right. I'll talk to marketing.” My fate was sealed...
Are there small projects?
Project Managers like to think about projects in a different way than the rest of the people involved on them. Maybe for historical reasons, a project is seen as a large effort to produce a unique product and service. When the word “project” is used, the word “large” is almost automatically attached to it. Yet, the PMBOK® GUIDE, on its definition of a project, does not mention anything related to size. It only mentions that it is a “temporary effort.”
Let us assume that projects are “large endeavours”. It seems very appropriate that a project then has a set of well defined phases, everyone of them taking some time to complete. In addition, it seems very appropriate that a very structured process needs to be in place in order to ensure the success of that project. The whole content of the PMBOK® GUIDE is created under the premise that a well-managed project has enough time to cover some, if not all, of those phases and projects. Or so it seems.
Let us know remove the assumption and say that there are temporary endeavours in which either, time is a premium or the project itself is of very short duration. Does this project need a stakeholder approval? Do the project manager need to plan some tasks? Do those tasks need to be controlled? Do the project manager need to assess the risks? The answer should be yes to all of those questions. The themes on the questions are part of the body of knowledge and, yes, all of them are important. In a sentence: the projects are not time bounded so there are small projects.
If there is still a shadow of doubt about this concept, it is easy to add another dimension to the discussion: resources. Do all companies have a project management team? Do they have enough resources to assign each of them to a single project or manage to deploy multiple projects at the same time? The answer is clearly no. As a result, are small companies condemned to develop their project-like endeavours in a way that affects their ability to create good products or services? It shouldn't. Even small companies should be able to benefit from a well conceived body of knowledge on project management. Of course their projects will be smaller than those of big companies, but that should not be a handicap on the business world. Small companies will most probably so small projects.
A real life case of small projects
At the onset of the Internet bubble, a small e-tailer found itself in a predicament: speed is everything. Dozens of companies with the same business models where fighting for cyber-customers all over the world. They needed to do things fast. “Things” called projects. Then the bubble exploded. This company was fortunate enough to have a business model that allow them to survive the downturn of the dot-coms. Everybody felt the pressure was gone; now things can be done more slowly, now there is time to think, to act and to deploy. But they were wrong.
As the internet users started to get more involved, the situation for the remaining internet companies changed dramatically. The few remaining HAD to be good, had to innovate, had to show that they were worth of the customer's loyalty. Small and fast projects were the norm, not the exception. Those projects were so small that no project management was being done.
As a general rule, business areas would come up with and idea for a new product. Somebody (sometimes the business users themselves, sometimes one of the developers) would create a “scope” and then write the “requirements”. Those requirements were passed on to a developer or a team of developers and they will code and deliver the final product, usually in production. It was then validated by the business owners (of course if there were problems, the customers would see them before people on the company knew about them) and the project was closed.
The rate of success, meaning that the product delivered was the product that was conceived, was, of course, very low. As there were no metrics it was impossible to say how bad the problem was, but everybody knew it was getting worst as the number of those small projects increased.
When a new management took over the company, it became obvious that, in order to survive, something needed to be done, and fast. The first major fix was to separate the business from the technical side of projects. From the project management perspective, one of the major inputs for any project is the business case and the business objectives, usually reflected in the project charter. By giving business people the responsibility to give business sense to the project, but transferring the responsibility of the delivery to the technical teams, it became clear that there was a requirement to have somebody actually managing the project on the technical teams. They will be responsible to scope the project and do whatever was necessary to deliver it on time and on budget.
The second major improvement was to give the projects a size. The company decided to use the “T-Shirt Size” concept. Projects were classified as Large, Medium and Small. Large projects were called projects, medium project were called mini-projects and small projects were called micro-projects. A micro-project was a project whose work estimation was anywhere between 8 and 40 hours of work, a mini-project was between 40 and 120 hours of work and a project was anything larger than that.
Project Life Cycle
As proposed by the Project Management Institute (PMI®) (PMI, 2004, p 23), every project should have a initial, intermediate and final phases and the project management involvement is specific to each one of those. Giving the fact that this company was dealing with very small and fast projects, is this a feasible approach?
Mini-Projects
The typical life cycle for mini-projects starts when the idea is presented to the stakeholders. The stakeholders rank those ideas by a variety of factors (immediate impact on customer satisfaction, revenue growth, cost reduction, risk involved, source of the idea, etc.). Once the ideas are ranked, they are assigned time-slots to be completed. Those time slots are usually related to business considerations (retail over the internet is a very seasonal business) and resource availability. The final step of this previous process in to create a Vision document; this is like a “business scope” and it is called a “Why” document (Why do we want to do this project?). For mini-projects this is typically a two to three pages document. This correlates very well to the Initial phase proposed by PMI.
Then the process falls in the hands of a project manager. A project manager can have at any given time between two and five of this small projects. When the project manager receives the Why document (already signed off by the stakeholders, of course), his first task is to create a “What” document (What do we want to build?). This document is the actual scope of the project and it could contain several of the typical components of a big project (see Project Management Processes applied to small projects). When the What document is approved, the actual execution starts. Once the project is completed, there is a formal closing (based mainly on the QA assessment of the product) and the project is handed over to operations. These phases are also very close to the Intermediate and final phases of the project life cycle proposed by PMI.
Micro-Projects
Under the current model, a micro-project is less roughly less than a week of work. It is very difficult to fit the traditional life cycle in such a short time. The product management team came up with the idea of using Total Quality Management (TQM) principles to manage this type of projects. The business areas responsible of defining and developing the product, create a rough draft of the idea (usually an improvement to an existing product) along with the stakeholders. This idea is written up in the form of a requirement (scope). By definition, this scope is already signed off by the business lines. The description is then provided to a project manager who is responsible to review it and find any technical gaps. Once the technical gaps are closed, the project manager, using a task tracking tool, assigns the work required to the resources and follow up on its development. The turn around time from the initial idea to the developed product is less than two weeks (assuming the resources had been allocated).
This is clearly a different approach to the one proposed by PMI. However, it is a logical approach because micro-projects are not aimed to revolutionize the way the company does business but improve one of its products. However, as it will be explained later, the project management role is instrumental on the success of those micro-projects.
Project Management Process applied to small projects
Once the Project Lifecycle was defined, the next problem found on the process of defining PM standards in this organization was how much Project Management was required to take this projects to a successful delivery. Using as a guide the PMBOK® GUIDE, the team began a practical approach: what should be required and what could we left out or try and then decide if we keep it, or not?
Mini-Projects
The project managers were clearly called to manage the project during delivery. This meant that an integrative approach was required. Project Managers own the Mini-project, create the scope and project plan, control and monitor the progress and manage change controls. For Mini-projects, a formal scope is created and a basic WBS is also made available to the team. There is a high level of involvement from the technical leads in this initial step as the scope is usually highly technical.
In order to create a WBS, a Deliverable > Task > Sub-Task tree is created based on the expert consensus of the scope. This process is usually supported by Mind Maps, created in brainstorming sessions. This is a very effective way to reach a very early agreement on the deliverables and the acceptance criteria of the Mini-Project. The organization has decided on purpose not to use tools like project for this small projects, as the overhead to document the planning and control is too high.
To define the activities, do the sequencing and develop a schedule, the project teams use a concept borrowed form the Scrum Methodology: the sprint planning. As the project must be completed in less than 120 hours, short milestones are planned (usually every two weeks). Using the Mind Map, the team extracts the activities related to the deliverables (WBS) and list the tasks in order of priority. Those with high priority will be developed first and those which lower priority are stored in a backlog. That backlog is revisited in the next planning meeting. If a change control comes a new tasks are generated, then the process is repeated from the beginning creating a new list of prioritized tasks and a new backlog. Any precedence is analyzed in this step. It is also very interesting to note that business owners and sometimes even stakeholders are invited to this process, as business requirements may alter the priority of some deliverables and tasks. These activities are the recorded on a task-tracking tool where activities are sequenced in a road map leading to a milestone.
As part of this project, the teams also hold an estimation meeting. In that meeting each deliverable is analyzed and an “ideal” time is assigned. As part of the history of the project, the “real” time is recorded and a correlation between the ideal and the real time is extracted for use on future projects.
The control of the schedule is made in two different ways: the Project Manager is responsible to keep the schedule up to date BUT each member of the team is responsible to update his own task list. The tracking tool allows for a complete reporting by resource and milestone, so it is very clear when something is falling behind the expected time frame.
A member of the QA team is part of the project team from the first meeting. This resource has to create the Quality control plan (usually a test plan) and it has to be part of the project efforts. As a general rule the QA team takes control of the project once the developments are ready, so they perform the Quality Control.
Mini-Projects are usually a two or three resource effort plus the Project Manager. The resources in this organization are organized as a virtual team. A functional manager manages those teams, but assignments for projects and mini-projects are made by the Project Manager based on the skills and knowledge of each member of the team. It is not uncommon that one resource is assigned to several projects and mini-projects at the same time. However, it is the responsibility of the Project Manager that those resources are not over-allocated. As a side note, this company is very well known for its open policies on personal time management, creating a special challenge because some people work at different times than others.
Communication is one of the key issues for the organization. Documents are an integral part of the project and time is always allocated and tasks defined to create the required documents. The organization also embraced the concept of a “Wiki” and the documents are stored in a very open but effective way and, by default, are created by the responsible resource. In addition, as part of the process, a daily “Scrum Meeting” takes place. It is a 15 minutes drill where the team members tell the team what they did in the last 24 hours, what they expect to do in the coming 24 hours and also if there are any blockers or unforeseen circumstances that are affecting the project. In addition a weekly 30-minutes stakeholder meeting is held to inform the advance of the project and make decisions, if required.
Left out on purpose are all processes related to cost, risk and procurement management. The main reason is that almost all project are internal and, as such, these component do not create any added value to the final product.
Micro-Projects
The Micro-Projects have a complete different approach. As it was previously explained, the business teams are responsible of creating the scope. Because they are of such a short life, no major processes are used. However, a Project Manager takes over the execution. The main reason is that it is not uncommon that the resources used in these micro-projects are also used at the same time in Projects and Mini-Project. As a consequence, Project Managers have a vested interest on the time required to complete those micro-projects.
The common practice is that tasks required to complete a micro-project are included as part of the sprint planning and they are also assigned a priority. In this way, the resources are guaranteed to have time allocated to activities leading to the delivery of the improvement. For some people on the company (of course with some disregard for the PMI's definition of a project) the micro-projects become one infinite running project with an always-increasing variable set of tasks, delivering small products (or improvements) every now and then. However, this approach has proven to be very effective.
The Results
This approach to mini and micro projects has been in place for the last 18 months, with some minor changes. Although not formal statistics were kept of the old model, the management of the company is very pleased with the results. Informal estimates put the current successful completion rate (defined as the project being delivered between one milestone of the initial proposal) close to 95%, up from 5% to 10%.
The effectiveness of the approach has also lead to more products and improvements being released in a given timeframe.
Lessons Learned
This being a small company, executing small projects, the learning curve has been painful but the results have proven to be more than it was initially expected. Some of the most important lessons learned are:
• Ownership of the project: Even the smallest projects require some level of ownership and accountability. The right balance between the Project Manager and the business areas is key when not many resources are available and when time is a very important factor
• Keep it simple and practical: Basic PM principles can be applied to any project. However, the organization should be very careful not to over blow the importance of each and every piece of the standard. It is very clear that following the standard gives body to the process but for small companies and small projects, keep it simple.
• Tools: Even the most well know tools in the PM arena seem to be very complex for small projects. Look around, there are very interesting open source tools. Also look for tools with specific functionalities (for example task tracking) as their core strength
• Do not be afraid to try or innovate: It should be very evident by now that this organization didn't follow any specific methodology or line of thought. There is something from several places that, pieced together, make sense for the business and type of projects. Some of the good pieces of the current process are the second or third attempt to find the right combination.
• Executive buy in: There is no way that any process, standard or practice can be successful if the management team is not involved early. Especially when dealing with a very small executive team, finding the right message and showing results is going to get the support of the whole organization
A little story, Epilogue
“Fortunately”, Joe told me later, “ I didn't believe my manager's assessment”. “When I went to talk to Marketing, they told me the application had not been tested in our PC and some technical guy from the vendor told us it was not going to work. I decided to talk to my manager”. Because Joe was a very good Project Manager he made the Marketing team agreed on what was the real scope of the project, talked to the IT department and found out what the process was to deploy a new application, hired an external resource to do a technical assessment on the tool, got training for the marketing users and documented the whole process for future reference. As a result, the manager, marketing, the IT team and the Project Manager lived happily ever after.