Understanding what a project is
It seems like a simple question, but have we ever thought about what is essential to our business? Before we can start strategizing on how to manage and sell projects, we need to understand what a project is and, even more important, what it is not.
Most people respond to the question by talking about activities, planning, meetings, due dates, documents, people, and objectives. This is how many of us think of a project, but can we call all engagements where people try to reach objectives by means of planned activities projects? The answer is, probably not. For example, in the production plants of automotive companies, people realize objectives and collaborate on planned activities, but we wouldn't classify those as projects.
Before we can speak about a project, we need to be certain about the unique and temporary character of our endeavor. Projects are temporary by definition, as they have well-defined start and end dates. Most of us are well-informed about the start date of our project; the end date can be more of a worry and is often confused with the Go-Live date of the brand new software solution. Projects are also unique by nature—not only because they produce unique deliverables, but also because the context for the execution is unique. Unique can mean that it has never been done before, or maybe it has been done in a very similar fashion before but never exactly in the same way. Therefore, no two projects, by definition, can be the same.
In most of the definitions of a project that we can find in literature, these key elements are well absorbed.
The Project Management Body of Knowledge (PMBOK) defines a project as:
A temporary endeavor undertaken to create a unique product, service or result. The temporary nature of projects indicates a definite beginning and end. The end is reached when the project's objectives have been achieved or when the project is terminated because its objectives will not or cannot be met, or when the need for the project no longer exists.
By implementing Microsoft Dynamics solutions, we implement ERP or CRM software functionalities, and from a product's point of view, many of these implementations are lookalikes. Then what makes these implementations unique?
Although we are implementing typical ERP or CRM functionalities, we need to implement unique business requirements for each customer. Every customer has unique demands for specific deliverables such as internal reports and customized functionality, matching their unique organization of the business processes. But even more important to note is the fact that people make these implementations unique. Implementing the solution in a customer context is always unique because we are always working with different people. They always have a different background, knowledge level, expectations, goals, and their own unique way of working. We also work with changing consulting implementation teams, based on the availability of our consultants, resulting in a unique context. So yes, the Microsoft Dynamics implementations are projects because they are unique and they are meant to be temporary. We always need to deliver our projects in a limited timeframe and no two engagements are the same. However, this involves a lot of uncertainty and so our Microsoft Dynamics engagements are characterized by uncertainty going hand in hand with risk (in ISO 31000:2009 risk is defined as the effect of uncertainty on objectives).
Now that we have understood what a project is, we also need to understand what it is not. Projects are not ongoing and repetitive; projects are not operations. Businesses driven by ongoing repetitive processes carry less risk because the context is much more controlled. In our projects, we do not have such controlled environments. We may know some of our key users, but we may not know all the key and end users of the system, and we also don't know how familiar they may be with business processes and business solutions. We do not know how well they communicate and how they perform in teams. There is so much that we don't know when planning a new engagement.
What matters is to be aware of these risks and to be aware that the business we are in is completely different as compared to an operations-driven business. Only then we can really start strategizing on how to manage and sell projects. Therefore, we should review our future proposals and plans, bearing in mind that we are planning for a project, which ultimately means planning for risks. We should plan how well these plans and strategies are covering the uncertainties.
Most definitions of a project include these elements of the unique and temporary character but do not specifically address them. The following are also a few other questions that need to be answered:
- Isn't it equally important to gain an understanding of the contractual and commercial matters?
- Are we delivering the projects?
- How are we involved in projects?
- Do we have project responsibility?
- Do we carry the project risks and to what extent?
The answers to these questions prescribe and justify how we will sell and manage our projects. Just outsourcing resources to carry out project tasks does not call for the same management as carrying all project risks in a fixed-price project.