THE CONCEPT

PROJECT IS NOT

THEORETICAL

USE THE DEFINITION OF ‘PROJECT’ IN YOUR DAILY

PROJECT PRACTICE

HOW DOES PMI DEFINE A

PROJECT?

The Project Management Body Of Knowledge (PMBOK)-guide defines the concept project, right in the beginning, more specifically in chapter 1 on page 4. The Project Management Institute defines a project as:

"a temporary endeavor undertaken to create a

unique product, service or result.”

Question now is how you can use a theoretical concept as above into your daily project management practice? You can use this definition to remember some important characteristics and principles when managing a project. Characteristics to be derived from this definition are: • A project is temporary; • A project results in a specific product, service or result; • A project is always unique (in its approach ànd in its result). Not derivable from the definition above, but to be complete, I like to add the following characteristics as well: • A project is objective/ goal oriented (and therefore needs to tie into the corporate strategy); • A project is a multi-disciplinary collaboration; • A project is (should be) a one-time initiative that has to be right from the start.

PRACTICE 1: MAKE USE OF THE

PROJECT’S TEMPORARY

CHARACTER

Starting with the first important characteristic to be taken away from this definition, namely the fact that each project is always a temporary initiative! Consequently, that means that every project, without any exception has a start, but also an end. A lot of project managers are in the beginning of the project concerned about the start-up activities, and they should!, but not solely… Therefore, start organizing the end of the project at the start of the project as one of the first steps to undertake. It is as crucial for the success of a project to start planning out how you are going to end it, than starting the project itself! Discussions you need to start right from the beginning are amongst others: • How you will transfer the project product or result? • Which project acceptance criteria are relevant to be considered? • Which product acceptance criteria will be important?, however, that these (product) acceptance criteria will be defined in detail as you go along in the first phases project. But the foundation for these acceptance criteria should be set right from the beginning. • Who will have the operational responsibilities after the project? • How is the transfer of this responsibility arranged? • Etc. Considering such important questions, will take time and effort. And getting to complete answers to these questions, will run you well into the development stages of the project. But please don’t wait until only a few weeks before the end of the project to start thinking about these important questions that relate to the end of your project. As a help, you can find some basic project start and stop checklists here.

PRACTICE 2: SENIOR MANAGEMENT

INTERACTION

A second way to use the definition of the concept ‘project’ is to present that definition to the senior management, steering groups and the project sponsor. We should understand that these people are not expert project managers, they actually are very experienced operational managers. And whilst they probably understand very well the principles of management and hopefully in most cases also leadership, they do not always understand the nuances that projects need to get them successfully managed. Senior executives will often use the word project, and they will even say that they have a lot of experience in being involved in projects, but in most cases, they have an incorrect view on what projects really are. They often have managed projects in the past with the use of operational management techniques, and therefore they believe they are experienced in project management. When I encounter senior management and start introducing them into basic concepts like the triple constraint, a work breakdown structure, project success factors, and show that with examples out of the practice, I often see that I bring “new things to the table”. Just note yourself how much the word project is used, and how many more explanations of that same word are used as well. Especially in environments with low project management maturity. In such low maturity environments, I tend to literally include, already in the first presentations on the project, for example at a first steering group meeting, the definition of the word ‘project’, solely displayed on one single slide. It allows me to attract senior and middle management’s attention to the unique nature of the project and the project product. It provides me a basis to request time and resources to: • discover what the project is about, • discuss the need to have the project product designed, • get the project organized by designing a project organization and a project timeline, which we, as project managers ultimately will call a project schedule. Including that definition into my management presentations, allows me as well to motivate why professionalized project management is needed and why it is different from operational management, which they all know about. Because they know about operational management, I tend to make on a second slide a comparison between project characteristics versus operational management characteristics. It will make it easier for them to understand project management when it is compared with something they know: their operational management activities and techniques. In the end, including a definition of ‘project’ in the first presentations to the management, allows me to explain both the added value of project management for the project at hand, and the expected benefits of disciplined project management will bring. I don’t have to tell you that talking about benefits is always a good motivator for senior management to free-up resources to handle the consequences that formal project management will bring.

PRACTICE 3: DECIDE IF PROJECT

MANAGEMENT IS REALLY NEEDED

It is not because somebody or an organization names a task or an initiative or an endeavor, a project, that that task/initiative/endeavor is a project! Again, in practice, we see that the word project is abused or wrongly used a lot. Sometimes the name of a client is used as a project because some installation tasks are to be performed. But those are rather repetitive and can therefore never be considered as a project. It is that kind of abuse that unfortunately leads to a lot of confusion about what a project and the related project management really is. You should be warned that when an initiative that is not really a project, is called a project, and people expect that you apply project management to handle that endeavor, it might be extreme management overkill, leading to less efficient and less effective results in the best case and total failure of that initiative in the worst case. For example, solving an (urgent) problem needs a quick fix. Because of the problem’s complexity, such a quick fix might take several weeks giving the impression that it is a project. But in the end, it is not, and it is probably better to apply ad-hoc management rather than overthinking a structural solution which might take time which is really not available. For that specific case: Time over Quality! Another example might be that an initiative is recurrent or is expected, after it has been performed for the first time, to become repetitive. Such an example can be the shut-down of a factory for its periodic maintenance, and which happens several times in a year. Whilst the very first shut-down might be considered a project, because all is new and unexplored, as from the second time, and certainly the third and the fourth time, given the maintenance activities follow similar patterns, it should be organized as part of an operational process. I always hope that the operational process design is part of the scope of that first maintenance project, and even better that the maintenance operations are designed as part of the scope of the initial (factory) installation. We should remember that operational (maintenance) management, because of its repetitive character, which is clearly not a characteristic of a project, is not to be handled in a project management way. From the moment there is a “smell of repetition”, you should not hesitate to choose operational management over project management. It will even be more efficient: • Repetition makes that each iteration, we will become more experienced, therefore better in the execution and therefore quicker and more effective, in other words, more efficient. • Repetition makes that we can design and document business processes, which can be used at any time they are needed. For each project, you need to start designing your execution process at the start, which takes time and resources whilst it can be avoided when a business process is available. Coming back to using the definition of ‘project’ in practice, I use the following criteria to suggest to management whether we will tackle the task at hand as a project or not: • When there is a repetitive aspect to it: no doubt and no hesitation, organize the task as an operational process. If the operational/business process is not existing: design it first. Note: initially designing that process might be a project! • When the initiative does not bring a new or unique result: organize it as well as an operational process. • When an one-time and quick fix is needed to solve a problem, and it is accepted that the fix might not be structural, attack it with an ad-hoc approach. Just do it and get things done! BUT; WHEN the initiative is about delivering a new and unique product, which needs to be a structural and lasting solution, to be realized before a specific due- date on which the realized product or service is to be transferred to the standing organization or operations, AND the initiative at hand has some “substance”, THEN it is very wise to call that initiative a "project" and to start applying project management. The substance criteria are important! Indeed, when you have a task that perfectly fulfills the theoretical project definition, but it only takes two days of work, to be delivered in one week’s time, it would be very senseless to start-up a project definition phase, which on itself might already take one day of effort to create a detailed statement of work, a risk management plan, a stakeholder analysis, a project schedule, etc. Typical “substance” criteria are manpower requirements, assigned budget, involved departments, estimated duration, and so on. The substance criteria themselves, the number of different substance criteria to be used, as well as the values of these criteria, are different in different environments and different organizations. In one organization, a task that takes 10 days of manpower combined with an estimated budget of 10.000,00 € might be a project, whilst the same task in another organization is merely a small task that will be done between the bulk of other tasks. Taking into consideration the project definition, in combination with some substance criteria, might be very helpful to decide whether you will handle a task in an ad-hoc way, or with operational management or as a project. The definition offers not only a guideline for taking that decision, but proves very valuable to also explain why you have chosen for a certain approach. The Project Management Institute (PMI) and the Project Management Body of Knowledge (PMBOK) - guide are registered trademarks and copyrighted. You can find more information on the website: www.pmi.org.

ABOUT THE AUTHOR

Steven GOEMAN is a certified project management professional and a licensed Master of Neurolinguistic Programming with more than 20 years of project (management) experience. He is the creative mind behind the renowned brand “The Project Management Mentor”, enabling him to share his expertise on portfolio management, program management and project management as an empathic project management coach and project management mentor. Steven founded GAPS BV (https://www.gaps.be) in 2005 from which he successfully assisted many individuals and organizations with project management related mentoring, coaching and consulting services. How to reference this article: Goeman, S. (2021, 23 February). The project concept is not theoretical. GAPS BV. https://www.gaps.be/Mentor/pmart002- pmbok_conceptproject.htm.