Nearly Universal Principles of Projects

This is a single page copy of the whole content in,
last updated on 2020-01-20.

You can open one or multiple language sections below, and then save/print the page as PDF or any other format.


NUPP is a collection of nearly universal principles of projects: those we’d do well to follow in all projects, regardless of the methodologies and approaches that we use, to maximize our success.

Each of the available resources and methods for running projects relies on some of these NUPs (nearly universal principles). However, the following points need to be borne in mind:

  • It’s usually not all of them, and it would be helpful for practitioners to consider all NUPs instead of a subset.
  • The underlying principles are usually not made clear enough in resources and methods, and most practitioners are so engaged in practical details that they forget about principles and do things that are not compatible with them.

NUPP is compatible with all the major methods, systems, resources, and frameworks such as PRINCE2®, PMBOK® Guide,, PM², DSDM®, XP, and Scrum. It may not be compatible with certain interpretations of those systems, though, and that’s where NUPP tries to encourage practitioners to reconsider their interpretations.

NUPP is a collection of the following NUPs:

Version 1.0, June 2019


Prefer results and the truth to affiliations

We all have a natural tendency to belong to groups, a tendency that often goes beyond its basic form, creates strong affiliations, and causes problems. We lose a lot more than we gain because of affiliations. We can become more professional and effective experts if we don’t limit our identity and preferences to certain groups.

Example: Agile vs waterfall

A group of highly enthusiastic people who were brave enough to try adaptive development approaches in IT development at the time when the norm was to use predictive approaches got together and called their approach “Agile”. This was a great initiative to not limit choices to what seemed to be necessary. There are still many enthusiastic and result-oriented people in the Agile community, but unfortunately, there are also some people in this community who turn Agile into a cult and consider all outsiders as enemies. This causes problems in multiple ways, including the following:

  • It doesn’t let them learn from anyone outside their group
  • It discourages outsiders from learning from them
  • It makes belonging to the group more important than the real purpose, which in turn prevents many of its members from learning the real meaning of Agility

This problem can be significantly reduced, if not removed, by using “Agile” only as a label that refers to a development approach rather than as a community with members; and by having people who consider themselves creators, problem solvers, and leaders, who see Agile simply as one of the enablers under their belt rather than as their identity.

There’s no Agile-waterfall war for real professionals.

Example: PRINCE2® vs PMBOK® Guide

There are many professionals in the community who associate themselves with either PRINCE2® or PMBOK® Guide (usually because of their geographical location) and are not familiar with the other. We can all have preferences toward certain resources, but not as our identity, and more importantly, we must familiarize ourselves with all of them to widen our perspective and choices.

The real professional is open to all ideas, looking for them, learning about them, and using them as and when needed, without affiliations.

Example: Continuous learning

Affiliations satisfy the person due to the feeling of belonging they engender, but don’t push them to learn, and sometimes even discourage them from learning for fear of losing them. When you’re a free person, an expert without affiliations, you need to fill in the gap with learning: with continuous learning.

What we believe in today is not the truth. It’s merely our best understanding so far, which has to be improved as we go on. There’s something wrong if one’s ideas are exactly the same as what they were a few years ago. This is even the case for NUPP: if you come back after a few years and see the exact same thing, you should become suspicious.

Example: Openness

When objecting to someone, make sure you’re aiming your objection at the idea, and not the person. This helps prevent a lot of tensions. In a similar vein, when someone is objecting to or about you, try not to interpret it as a war against you, but rather a discussion of your ideas, and stay open to it. Don’t listen to respond, listen to understand; and work with the other person to improve the idea.

Some people may intentionally target you instead of the idea, in which case, you should help them focus on the idea instead of on you before proceeding, and try to keep it like that throughout the conversation.


Preserve and optimize energy and resources

Resources are limited. Resources available to the project are limited, as is the mental energy you have to make good decisions. You should preserve and optimize this resource for yourself and for the project, and help other team members do the same.

Example: The 80/20 rule

A large portion of the possible benefits of project management can be gained by expending a small portion of the effort. In most cases, targeting 100% of the possible benefits is very expensive and unjustifiable. You need to consider this rule in everything you do and encourage others to do the same.

Example: Decision fatigue

We use a single source of mental energy for making all types of decisions, and also to express willpower. If you use up a lot of this source on making unnecessary or unimportant decisions, you’ll have less energy for the important decisions, which may lead to poor results. This is one of the reasons you should avoid micro-management (the “manage by exception” principle of PRINCE2®).

Conflicts that are about ideas can be helpful, but those that are about people are usually harmful to the project, and one of the consequences is that it drains the mental energy of the team members. If you notice such a conflict, you should do your best to find the root cause and solve it.

Example: Take care of yourself!

The decisions you make and the willpower that you express use up your source of mental energy. On the other hand, this source is filled with energy when you sleep and eat properly. So, you should take good care of yourself: make sure you have enough sleep and rest, and eat well. If you have harmful habits or problems with sleep, you don’t have to deal with it alone; there are many specialists who can help you fix such problems. Physical activity may also help with this source of energy, although studies are not yet conclusive on this matter.

Try to encourage the team members to do the same as you do. First, make sure they work at a sustainable pace and without too much overtime. Then, if you have the choice, try to offer energetic, healthy food, snacks, and drinks during work time.

Example: Work-life balance

Many of us love what we do, but that’s still not everything we need to have in life. In the same way that you optimize your work, you should be planning and implementing ideas in your personal life, in ways that make it a joyful, happy one. When you’re happier, you can be more successful at work too. If you can, try to encourage your team members to do the same.

Example: Motivation

Motivation is a complex concept. There are some interesting and useful resources on the topic, as well as many more unscientific ones. Nevertheless, you should learn about it and use it continuously, as it increases the mental energy of the team and the possibility of achieving better results for the project.

Motivation can be as simple as letting people know that you’ve recognized their good work by a kind smile or a simple “thank you”. However, you need to be careful, because many of the common forms of motivation, such as small monetary rewards, have a negative effect.

Example: Collaboration and teamwork

People who are collaborating may sometimes have the power to create better results, but more importantly, humans are social and enjoy being part of a group. If you can remove the negative aspects of teamwork and create a pleasant environment, there will be happier team members in the project.

You should be careful, though, because people are different, and some need more relaxed, focused, and solitary time than others do; it’s usually a balancing act.

Example: One-team culture

There’s a tendency for different stakeholders to create or consider subgroups and cause tension with other groups; for example, people who are focused on the business aspects of the project vs. people who are building the product. This tension consumes a lot of energy from both sides, which is one of the reasons we should try to build a one-team culture, where everyone works together towards the same goal.

Example: The wisdom of crowds

When a large number of people with diversity get together and work in a facilitated environment, there’s the potential to get very good results, ideas, and solutions, that may be even better than those coming from single experts.

If you have that option, you can use it regularly to ask team members to help you solve difficult problems in the project. Beside the possibility of getting good results, it also allows team members to know that their opinions are appreciated and that they play an important role in the project, which in turn increases their level of energy. Activity #26 of is an example of using the wisdom of crowds in projects.

Example: Chief project facilitator

If you are a project manager, most of the things you do have a facilitation nature (or at least, should have). On the other hand, you may see that the team members have had bad experiences with project managers in the past, and that these experiences are impacting on their relationship with you: a portion of their energy is spent on analyzing your behavior for potential threats instead of trusting you. In that case, you can change your title from project manager into Chief Project Facilitator. After all, that’s what you really do in the project.


Always be proactive

There’s a natural tendency in us to be reactive. It can help us preserve our energy dealing unimportant matters, or it may give us better results when we are dealing with something in which we’re completely incompetent. Those situations are different from our projects, and here we can get better results by being proactive.

Example: Planning

If you want to drive to a new location and you’re late, you can start driving immediately to “save time”, and deal with possible problems when they arise. The proactive approach is to take some time at the start and set your navigation system to give you the fastest route based on the traffic and possible accidents and blockages and then drive; that’s spending time before executing, to avoid problems later on and thus save time in the end.

In contrast to what some people think of Agile projects, planning is always necessary, and it’s only about the type and level of details in plans. Planning before executing is a proactive approach.

Remember the quote: give me six hours to chop down a tree and I will spend the first four sharpening the ax.

If it’s a predictive project, you may spend 4 hours sharpening your ax, because you’re sure that you’re going to chop down a tree. In an Agile project, you’re not sure if you’re going to chop down a tree, gather broken branches, harvest turf, mine coal, or something else. Nevertheless, you still need to have a general preparation for all of those (know where the nearest hardware store is), and have a specific preparation (sharpening) when you’re going to focus on a certain solution; that’s planning.

Example: Planning the planning

Planning the way we’re going to execute the project is a proactive approach. This proactivity can even be extended by planning the way we’re going to plan the execution; that’s the management plan concept of the PMBOK® Guide, management strategies of PRINCE2®, and approaches in DSDM®.

Example: Continuous planning

Reality rarely matches what we have planned, and that’s OK – but, we have to continuously adapt our plans to make sure they stay realistic and practical. We should do it as soon as adaptation is needed, and not when we run into problems. That’s a proactive approach.

Example: Risk management

The whole concept of risk management is based on proactivity: when facing uncertain events, instead of waiting to see what happens and then reacting to them, we think about possibilities and impacts, consider responses, and probably do something about it before it happens.

Note that what we do in projects is serious; it’s sometimes about people’s lives.

Example: Define roles and responsibilities

You can leave the project team members to work without clear roles and responsibilities, and sooner or later a form of roles and responsibilities will emerge, but it’s too expensive and may not work well after all. The proactive approach is to define them early and adapt them as needed. This makes working easier for everyone, and they can focus on producing something, instead of deciding who does what.

The number and variety of roles depend on the type and size of the project; it can be a simple definition such as the one in Scrum, something moderate such as that in, or something comprehensive like the ones in DSDM® and PRINCE2®. However, don’t forget that the role descriptions in these methods are only about management activities, and that you always need to add role descriptions for technical aspects as well.

Example: Available choices

Should you close the project prematurely or continue with it?

There are rarely only two choices, even if the question implies that. You need to have a proactive approach and consider all your choices before making a decision. Maybe you can rescope the project; maybe you can pause it until something else becomes clear; or maybe you can change the project approach (e.g., outsourcing), etc.

Example: Critical thinking

We all have many biases that help us survive on one hand, and fool us into making bad decisions on the other. When it comes to making important decisions about the project, it’s best to pause for a while and consider all biases that can impact our decision before they cause problems.

As a reference, you can use the list of cognitive biases given in Wikipedia:

There are even decision-making frameworks that you can use to make better decisions. At first, it may be distracting and even annoying to use them, but soon you get used to them and gain advantage from them without much conscious effort.

Example: Transparency

We don’t like being late in the project or having any other kind of problem, but it doesn’t mean that we should hide it. You should be transparent and let the stakeholders know, because some of them may be able to help you, and furthermore, they will know about the problems and their consequences sooner or later, and some of them may require early actions from their side (e.g., to accept the negative consequence).

Example: Communicate effectively

There may be many cases in which you send reports to stakeholders and they don’t give you any feedback. You may believe that everything is fine just because there is no negative feedback, although it may not be so. You have to be proactive and check to see whether they’ve really used the report and whether it has served the purpose, and use the input to adjust your method of communication; otherwise, this hidden issue may cause serious problems later, when it’s too difficult to fix.

Example: Take responsibility

It’s easy to blame others for poor results. For example, you may want your organization to give you full authority to change everything in the project and do it perfectly, but they don’t, and as a result, the project fails. This is not a proactive approach.

The proactive approach is to take responsibility and do everything you can within the constraints. You cannot expect the organization to fully trust you and give you everything in the hope of getting good results, especially when they have seen so many failed projects. What you have to do is to make one small improvement within the constraints that are set, use that to gain a little trust, a few more resources and a little more toleration for constraints, and then use that for a slightly bigger improvement, and carry on like that until you reach the optimum target.


Remember that a chain is only as strong as its weakest link

There are various domains in projects, and they all need attention; we must have a holistic perspective of the project. Paying attention to a seemingly important domain (e.g., time) is not enough, because all domains interact and they don’t work properly unless they all receive adequate attention.

Example: It’s all about the deadline!

Let’s say you’re building something for the Olympic Games. It has a very serious deadline, which makes time management very important. Is that right, though? What if the quality is so low that it necessitates repeat work after a while. That would impact on time, So, that makes it time and quality. You may have a fancy garden listed in the original definition of the project, but you know that if there’s not enough time, you can skip it and just cover it with grass, as long as you have considered this possibility in time and have prepared for it. So, scope management is also important. Now we have the scope, time, and quality domains at the center of our attention.

Have you heard of that famous example where president Kennedy meets a janitor in NASA and asks him what he does, and he replies, “I’m helping put a man on the moon”? Doesn’t having that type of people in the project help meet the deadline?

As you go on, you notice that every single domain in the project contributes to time management, and you can’t meet the deadline with an acceptable level of certainty unless you pay attention to all domains.

Example: Cherry picking

When people are faced with a variety of methods, sometimes they start cherry picking and create a mix of everything that seems interesting from different systems. This usually doesn’t work, because elements do not work in isolation and have to be compatible with each other. Any additions or changes to a system should be made from a holistic viewpoint.

This is why we sometimes see contradictory elements in different methods; something works well in one system, and its opposite works well in another system. That element is not right or wrong on its own.

The safest approach is to select a methodology for the project, tailor it, and then cautiously add new elements to it by considering the consistency of the whole system.

Example: The anti-process approach

One of the best things Agile methods have done is to draw attention to human aspects. The Agile Manifesto gives more value to individuals and interactions compared to processes and tools, although this may not be a fair comparison. Almost all methods say that human aspects are important, and the real difference with Agile methods is that human aspects are an embedded part of their processes, rather than a simple suggestion. So, it’s not about a competition between human aspects and processes, but rather about the way human aspects are seen in the system.

There’s no doubt that some people try to replace the human aspects by having more sophisticated processes, but that’s only a misuse. Even the opposite exists as well: people trying to replace processes with human aspects, which doesn’t work well either.

Example: These are all the domains you need

When thinking about the domains, you should be careful not to miss any of them. What are they, though? If you check the fundamental resources, you will receive different answers; and yet, none of them is the whole truth.

PRINCE2® themes are domains, but those are only the domains that play a key role in the methodology. The other domains are only implied.

The PMBOK® Guide is not a methodology and can formulate it much better with the ten knowledge areas. However, these are interpretations of all domains based on the PMBOK® Guide’s perspective on the project, rather than a neutral one (not that there necessarily is a neutral perspective). For example, human aspects don’t receive a lot of attention in the PMBOK® Guide.

A good source of information about the domains is ICB. However, it’s not about the domains, but about the competencies that are required in the project. It doesn’t have a one-to-one relationship with the domains, but it does help a lot in identifying them.

There’s no list of domains in NUPP, primarily because it’s a meta-system rather than a system, and also because the categorization of the domains depends on the type of project and its environment; e.g., a routine construction project may need a different perspective from a creative research project.


Don’t do anything without a clear purpose

You shouldn’t do anything unless it has a clear purpose. Imagine two parallel worlds where everything is the same except for the thing that you’re considering doing: How different would those worlds be? Is the difference worth the effort to do that thing?

If you don’t have a clear purpose in mind and are only doing something because everyone else is doing it, or everyone says that it’s important to do it, then

  • it may not have a real benefit in your case, and therefore you may not get anything out of it; or
  • it may still have potential benefits in your case, but because you don’t have the purpose in mind, your way of doing it may not help realize the benefits.

Example: Portfolios and programs

If you’re involved in selecting and initiating projects, you should make sure that you focus on the benefits and the problems that are required to be solved rather than the product that is going to realize those things. The classic example is the manufacturer of elevators who used to receive complaints about the speed of their elevators, and so had ran multiple projects to increase speed, without complete success. That continued until they decided to focus on the problem (people’s boredom or discomfort) instead of the “natural” solution (faster elevators). The result was that they added mirrors to elevators, and it solved the problem simply and cheaply.

Remember that project management is mainly about doing things right, while portfolio management is about doing the right things. It doesn’t matter how well you run your projects; it won’t work well if you’re doing the wrong projects. It’s all about having a purpose.

Example: Project as a whole

The flexibility of the product varies between projects. In some IT development projects, the product is completely flexible, and its final form depends on the feedback that will be generated by the increments of the product during the project, which requires an adaptive (Agile) approach. This is in practical terms a combination of the portfolio, program, and project layers, and needs maximum attention paid to the ultimate goal. It is a good idea to document the purpose and have it accessible; it’s one of the purposes of “product vision”, as used in some Scrum projects. The attention to business value in Agile projects is their way of ensuring alignment with purpose.

In other types of project, where the product is relatively fixed and there are other mechanisms to ensure that the identified product will satisfy the purpose, it’s possible for the project team members to shift a large part of their focus from the purpose to the product (hence the “focus on products” principle of PRINCE2®), but at least minimal attention to the purpose is still required to ensure that what is being built will satisfy the purpose, which can be done by comparing the forecasted benefits with the expected benefits (hence the “continued business justification” principle and the “business case” theme in PRINCE2®).

When a project is run for a external client, the client would have their own purpose for the project, and your company would have a different purpose. You should understand and use both of these to really succeed.

Example: Project monitoring

Focusing on the ultimate purpose is necessary, but it may be too abstract for many of the day to day uses. That’s why a hierarchy of drivers is needed to make it more practical. First, the justification and benefits of the project are defined based on the ultimate purpose, and then you will have explicit and implicit targets for project variables (e.g., time, cost, and quality) to satisfy the justification, which in turn will satisfy the ultimate purpose. These are lower-level purposes that are useful for many of our daily tasks.

When it comes to monitoring, the low-level monitoring of the project will be done using the lowest level of variables, because it may not be possible to track the ultimate purpose. In this case, you should still have the purposes in mind: what is the purpose of monitoring?

A normal and acceptable answer is to see whether we’re on track, and if not, to trigger a certain reaction that will bring us back on track or adjust the targets and see whether it can still satisfy the ultimate purpose. Our measurements should therefore be able to help with this low-level purpose, and the appropriate measurements are forecasts for the variables at completion; e.g., when would we be able to finish the project? How much money would we need to finish the project?

All other measurements, such as the planned and actual values to date, are just interim values that you need in order to calculate the forecasts, not the final values that you use for managerial purposes.

Example: Documents

No matter what development approach you use in the project, planning is always necessary. The important question is the level of detail in each type of plan. If there’s not enough detail in the plan, the plan won’t be able to contribute enough, and executing the project will be based on ad hoc decisions rather than integrated, holistic ones. On the other hand, many people try to be cautious and add too much detail to their plan, which makes it too difficult to prepare and maintain, and too rigid for the uncertainties of the project. As a result, the plan becomes unrealistic and useless.

The best way to decide about the level of detail is to have a purpose in mind for every element in the plan. For example, if you’re considering the addition of resources to the plan, you should have a purpose for it: How are you going to use it? How will it help the project? How much effort will it take? and is it worth it?

It’s sometimes about deciding whether you want to have a certain element in your plans, and sometimes about the way you want to plan or prepare something. Whether it be a business case, a project charter, or a report: you should still ask yourself why you’re preparing that document and how it can help the project.

Looking for a “template” is the opposite of doing something based on a purpose.

Example: Status reporting

It’s common to have really long status reports in many projects. Based on this NUP, we should ask ourselves what the purpose of the report is and how we can achieve that purpose regardless of what most other people may be doing.

This can, in many cases, lead us to prepare very simple one-page reports that stakeholders really read and understand instead of long reports. This is paying attention to purpose.

If you prepare one-page reports, though, some people may object about you and think that you don’t have a “proper” monitoring system in place. In practice this creates a second purpose for you (besides the first purpose, which is helping stakeholders understand the status of the project), and to satisfy that, you can simply create a second type of report that is very long. However, you won’t mix that with the first report, because these two purposes are not the same.

Example: Business case and project charter

Preparing documents such as a business case and a project charter is usually a boring, fruitless, bureaucratic necessity for most people, while these documents all have valid purposes that apply to most projects. If you try to find a “template” and fill it in, the work is just wasted; whereas you can instead check the real purpose of those documents, see whether and how they can be helpful in your project, and then prepare the document in any way you like, just to satisfy those purposes: that will be the right document.

While you’re thinking about the way you can prepare the documents to satisfy their purposes, you may not think of every scenario and may miss something. To avoid that, you can check to see what resources such as PRINCE2®, PMBOK® Guide,, and DSDM® suggest, and then evaluate those suggestions based on the purposes.

Example: Post-project

While the project has a specific purpose, and we can consider that purpose throughout the project, the realization of the purpose is mainly evaluated based on forecasts made during the project. We should not, however, forget about it when the project is finished. It is important to check the realization of the goals after the project is finished, because

  • we can see how the ultimate goals are achieved and learn from that for future projects, and
  • sometimes the goals are achieved only when we carry out some additional tasks after the completion of the project, and understanding the necessity of those extra tasks needs monitoring.

Post-project monitoring is a necessary step in being purpose-driven. It’s mainly the responsibility of program and portfolio management systems, and because most companies do not have such layers of management, this step is usually neglected. That’s why methods such as and DSDM® add this step to their project management methodologies.

Example: Simplicity

The world is complex and chaotic, but our models are abstract approximations that reflect parts of the world, and hence, they can be simple. On the other hand, simple systems usually work better, because we can be focused on the main idea.

Many of us try to get better results by adding complexity to our systems, hoping that it will match the complexity of the world, even though in practice this makes the system difficult to work with and usually blocks us from satisfying the purpose.

Example: Tailoring

A piece of software for streaming music has a very different condition from one that will be used for equipment in a hospital or a on plane where people’s lives may depend on it, or from a piece of software that will be used in a satellite where it’s supposed to work for many years without crashing, and they are all different from building a summer villa, a fire fighting station, and a process plant.

When you have the purposes in mind, you will better understand how to tailor the systems and artifacts for different projects.


Use repeatable elements

An ad hoc approach to the project takes too much energy and resources, and always runs the risk of missing some of the necessary elements. The best way of simplifying what has to be done is to use repeatable elements, and preferably to take them in repeatable cycles.

Example: Quality checklists

A checklist is a simple example of a potentially repeatable element that many people use in their personal and professional lives. Take quality criteria of a deliverable, for instance:

  • First, you may create a checklist of all criteria, which is a form of planning.
  • What NUP6 recommends is to try to generalize it: are there other similar deliverables in the project? In that case, prepare a general quality checklist for that category of deliverables and use it for all of them. If there are some variations, keep the generic list, and add a few extra items for the individual deliverables. Now you have repeatable checklists.
  • Once you have prepares generic checklists for various types of deliverables, you may find elements that repeat among them, which suggests a virtual parent category for them. In that case, instead of repeating the items for all those generic checklists, you can extract them and put them in a parent checklist. In the end, you will probably have a single generic checklist for the whole project. Scrum’s “definition of done” is an example of using project-level checklists for quality (possible among other things). By doing this, each deliverable will belong to a hierarchy of categories and should satisfy the items that appear in checklists of all categories in their chain.

By doing this, an item in the parent checklist will become repeatable for all deliverables underneath it, which saves time and energy in planning and execution.

More importantly, once you do this for one project, you can tailor and use it for all similar projects in the future, which is a repeatable form of planning for multiple projects.

Example: Processes and workflows

Some deliverables, or goals linked to them, need certain steps that can become standardized and repeatable. For example, if the deliverables need to be designed individually and approved, you can prepare a simple workflow that makes all the steps, people involved, and approximate durations clear, so avoiding many difficulties. You should be careful, however, not to make the workflows and processes too complicated or too intensive in documentation, as it will have a negative consequence. All people involved in the project should see the workflows and processes as something that supports their work and makes everything easier for them, rather than as bureaucratic documentation that blocks their real work.

Agile projects have repeatable elements in their iterative development approach, where certain type of development activities are repeated for every feature; e.g. the common daily routine in XP (eXtreme Programming): pair up, pick an item, design it on a whiteboard, build the test scripts and code, integrate the code, etc.

Beside the repeatable workflows that can be used for technical activities, you can have repeatable elements for the project management activities as well. The processes in the PMBOK® Guide, PRINCE2®, and DSDM®, the activities in, and events in Scrum are examples of this concept.

Example: Cycles

Having repeatable elements for managing the project is helpful. This can be made even easier by putting them into repeatable cycles. These cycles significantly simplify the day-to-day activities of people involved in the management and leadership of the project. Cycles of process groups in the PMBOK® Guide when used in a project with multiple phases, stages in PRINCE2®, daily, weekly, and monthly cycles in, iterations and timeboxes in DSDM®, and Sprints in Scrum are all examples of this concept.

Shorter cycles are easier to understand and use than longer ones; e.g., Sprints in Scrum in contrast to the phases according to the PMBOK® Guide. However, cycles that are too short may not be enough to support certain types of project, and the solution can be the use of multiple cycles, such as DSDM®’s use of short timebox cycles along with longer iteration cycles, or’ use of daily, weekly, and monthly cycles.

Example: Methods

Using a methodology or a framework for running a project is another use of repeatable elements. This can be an existing system such as PRINCE2®,, DSDM®, or Scrum, or one that you’ve customized or built yourself. However, it’s normally a better idea to start with one of the existing methods and adapt it to your needs than to build it from scratch.

Any repeatable element is abstract and needs customization to adapt it to the real world. There’s a spectrum of abstraction and need for customization, though: small, relatively concrete quality checklists are at one end of the spectrum with the least amount of abstraction and need for tailoring, while methodologies are at the other end, with the highest need for tailoring. You should always note the need for tailoring, otherwise, the repeatable element won’t match your needs properly.


NUPP is een verzameling van Nagenoeg Universele Project Principes: die principes waar we goed aan zouden doen om ze in elk project te volgen, welke methodologie of benadering er ook wordt gebruikt. Ze hebben tot doel om de kans op slagen van het project te maximaliseren.

Elk van de beschikbare bronnen en methoden voor het uitvoeren van projecten steunt op sommige van deze NUP’s (Nagenoeg Universele Principes). De volgende punten moeten hierbij echter in gedachten gehouden worden:

  • Meestal steunen ze niet op alle NUP’s, en voor de gebruiker zou het beter zijn om het geheel aan principes te overwegen in plaats van slechts een subset.
  • De onderliggende principes worden in die bronnen en methoden vaak onvoldoende duidelijk gemaakt, en de meeste gebruikers verliezen zich in de praktische details zodat ze die principes vergeten en dingen beginnen te doen die er niet meer mee overeenstemmen.

NUPP is compatibel met alle veelgebruikte methoden, systemen, bronnen, en frameworks zoals PRINCE2®, PMBOK® Guide,, PM², DSDM®, XP, en Scrum. Mogelijk is NUPP echter in contradictie met een interpretatie van één van deze systemen, en hier wordt de gebruiker aangemoedigd om zijn/haar interpretatie te heroverwegen.

NUPP is een verzameling van de volgende NUP’s:


Geef de voorkeur aan resultaten en feiten i.p.v. affiliaties

We hebben allemaal de natuurlijke neiging om tot groepen te behoren, een neiging die vaak verder gaat dan zijn basisvorm, sterke verbondenheid creëert en problemen veroorzaakt. Door affiliaties verliezen we veel meer dan dat we winnen. We kunnen professionelere en effectievere experts worden als we onze identiteit en voorkeur niet beperken tot bepaalde groepen.

Voorbeeld: Agile vs. Waterfall

Een groep zeer enthousiaste mensen die de moed hadden om een adaptieve ontwikkelingsaanpak in IT-ontwikkeling te proberen op een moment dat het de norm was om gebruik te maken van een voorspellende aanpak, kwam bij elkaar en ze noemden hun aanpak “Agile”. Dit was een geweldig initiatief om de keuzes niet te beperken tot wat noodzakelijk leek. Er zijn nog steeds veel enthousiaste en resultaatgerichte mensen in de Agile-gemeenschap, maar helaas zijn er ook mensen in deze gemeenschap die Agile tot een sekte maken en alle buitenstaanders als vijanden beschouwen. Dit levert op meerdere manieren problemen op, waaronder de volgende:

  • Het laat hen niet toe om te leren van iemand buiten hun groep
  • Het ontmoedigt buitenstaanders om van hen te leren
  • Het maakt het behoren tot de groep belangrijker dan het werkelijke doel, wat veel van haar leden ervan weerhoudt om de werkelijke betekenis van Agility te leren kennen

Dit probleem kan aanzienlijk verminderd, zo niet verwijderd worden, door “Agile” alleen te gebruiken als een label dat verwijst naar een ontwikkelingsaanpak in plaats van als een gemeenschap met leden; zodat daarbij mensen zichzelf als bedenkers, probleemoplossers en leiders beschouwen, die Agile eenvoudigweg zien als één van de tools in hun rugzak in plaats van als hun identiteit.

Er is geen Agile-watervaloorlog voor echte professionals.

Voorbeeld: PRINCE2® vs PMBOK®

Er zijn veel professionals in de gemeenschap die zich associëren met PRINCE2® of PMBOK® Guide (meestal vanwege hun geografische locatie) en de andere niet kennen. We kunnen allemaal voorkeuren hebben voor bepaalde bronnen, maar we moeten ze niet beschouwen als onze identiteit, en wat nog belangrijker is, we moeten openstaan voor alle bronnen om ons perspectief en onze keuzes te verbreden.

De echte professional staat open voor alle ideeën, zoekt er naar, verdiept zich er in en gebruikt ze waar en wanneer nodig, zonder affiliaties.

Voorbeeld: Voortdurend blijven leren

Affiliaties bevredigen de persoon door een gevoel van samenhorigheid, maar dwingen hem niet om te leren - sterker nog - soms ontmoedigen ze hem of haar zelfs om te leren uit angst om de groep te verliezen. Als onafhankelijk persoon, als expert zonder affiliaties, moet je die leemte in te vullen met leren, met permanent bijleren.

Waar wij vandaag in geloven is niet de waarheid. Het is slechts ons beste begrip ervan tot nu toe, dat moet worden verbeterd naarmate we verder gaan. Er is iets mis als iemands ideeën precies hetzelfde zijn als een paar jaar geleden. Dit is zelfs het geval voor NUPP: als je binnen enkele jaren terugkomt en precies hetzelfde ziet, moet je achterdochtig worden.

Voorbeeld: Openheid

Als je bezwaar maakt tegen iemand, zorg er dan voor dat je je bezwaar richt op het idee en niet op de persoon. Dit helpt veel spanningen te voorkomen. Als iemand bezwaar heeft tegen of over je, probeer het dan niet te interpreteren als een oorlog tegen jezelf, maar als een discussie over je ideeën, en blijf er open voor staan. Luister niet om te reageren, luister om te begrijpen en werk samen met de andere persoon om het idee te verbeteren.

Sommige mensen kunnen zich bewust op jou richten in plaats van op het idee. In dat geval moet je hen helpen om zich op het idee te concentreren in plaats van op jou voordat je verder gaat, en proberen dit zo te houden gedurende het hele gesprek.


Behoud en optimaliseer energie en middelen

Middelen zijn beperkt. De middelen die beschikbaar zijn voor het project zijn beperkt, evenals de mentale energie die je hebt om goede beslissingen te nemen. Je moet deze middelen voor jezelf en voor het project behouden en optimaliseren en andere teamleden helpen om hetzelfde te doen.

Voorbeeld: De 80/20 regel

In project management kan een groot deel van de mogelijke opbrengsten (ongeveer 80%) worden verkregen door het inzetten van een klein deel van de energie en middelen (20%). In de meeste gevallen is zich richten op 100% van de mogelijke opbrengsten zeer kostelijk en niet gerechtvaardigd. Deze regel moet in gedachten gehouden worden bij alles wat u doet en u doet er goed aan anderen aan te moedigen om hetzelfde te doen.

Voorbeeld: Beslissingsmoeheid

We hebben slechts één bron van mentale energie om alle soorten beslissingen te nemen en om uiting te geven aan onze wilskracht. Als je een groot deel van deze bron gebruikt voor het nemen van onnodige of onbelangrijke beslissingen, heb je minder energie voor de belangrijke beslissingen, wat kan leiden tot slechte resultaten. Dit is één van de redenen waarom u micro-management moet vermijden (het “manage by exception” principe van PRINCE2®).

Conflicten die over ideeën gaan kunnen nuttig zijn, maar conflicten die over mensen gaan, zijn meestal schadelijk voor het project en één van de gevolgen is dat het de mentale energie van de teamleden uitput. Als u een dergelijk conflict opmerkt, moet u uw best doen om de onderliggende oorzaak te vinden en op te lossen.

Voorbeeld: Zorg goed voor jezelf!

De beslissingen die je neemt en de wilskracht die je tentoonspreidt, gebruiken je mentale energiebron. Aan de andere kant wordt deze bron gevuld met energie als je goed slaapt en eet. Zorg dus goed voor jezelf: zorg voor voldoende slaap en rust, en eet goed. Als je schadelijke gewoontes of slaapproblemen hebt, heb je daar niet alleen mee te maken; er zijn veel specialisten die je kunnen helpen dergelijke problemen op te lossen. Lichaamsbeweging kan ook helpen met deze energiebron, hoewel de onderzoeken hierover nog geen uitsluitsel geven.

Probeer de teamleden aan te moedigen om hetzelfde te doen als jij. Zorg er eerst voor dat ze in een duurzaam tempo en zonder al te veel overwerk werken. Probeer vervolgens, als je de keuze hebt, energieke, gezonde voeding en drankjes aan te bieden tijdens de werktijd.

Voorbeeld: Werk-privé balans

Velen van ons houden van wat we doen, maar dat is op zich niet voldoende voor een leven met voldoening. Net zoals je je werk optimaliseert, zou je ook in je persoonlijke leven je ideeën moeten plannen en implementeren op een manier dat ze je leven vreugdevol en gelukkig leven maken. Als je gelukkiger bent, kun je ook succesvoller zijn op je werk. Probeer je teamleden aan te moedigen om hetzelfde te doen als jij.

Voorbeeld: Motivatie

Motivatie is een complex concept. Er zijn een aantal interessante en nuttige bronnen over het onderwerp, en er zijn nog veel meer onwetenschappelijke bronnen. Desalniettemin moet je er meer over leren en er voortdurend bij stilstaan, want motivatie verhoogt de mentale energie van het team en daardoor ook de slaagkans van het project.

Motivatie kan zo eenvoudig zijn als mensen laten weten dat je hun goede werk waardeert door een vriendelijke glimlach of een eenvoudige “dank je wel”. Je moet echter voorzichtig zijn, want veel van de gebruikelijke vormen van motivatie, zoals kleine financiële beloningen, hebben een negatief effect.

Voorbeeld: Samenwerking en teamwork

Mensen die samenwerken hebben soms de capaciteit om betere resultaten te creëren. Belangrijker nog is dat mensen sociaal zijn en graag deel uitmaken van een groep. Als je de negatieve aspecten van teamwerk kan elimineren en een prettige omgeving kan creëren, zullen de teamleden in het project gelukkiger zijn.

Je moet wel voorzichtig zijn, want mensen zijn verschillend, en sommigen hebben meer ontspanning, concentratie en tijd voor zichzelf nodig dan anderen; het is meestal een evenwichtsoefening.

Voorbeeld: Eén-team cultuur

Er is een tendens bij verschillende stakeholders om groepen te creëren of te overwegen, en spanningen tussen deze groepen te veroorzaken; bijvoorbeeld mensen die zich richten op de zakelijke aspecten van het project versus mensen die het product bouwen. Deze spanning kost veel energie aan beide kanten en dat is een van de redenen waarom we moeten proberen een één-teamcultuur op te bouwen, waarin iedereen samen aan hetzelfde doel werkt.

Voorbeeld: De wijsheid van de massa

Wanneer een groot aantal mensen met diverse achtergrond samenkomen en in een gefaciliteerde omgeving werken, bestaat het potentieel om zeer goede resultaten, ideeën en oplossingen te behalen, soms zelfs nog beter dan die behaald door individuele deskundigen.

Als u de mogelijkheid hebt, kunt u deze techniek regelmatig gebruiken en teamleden vragen u te helpen bij het oplossen van moeilijke problemen in het project. Naast de mogelijkheid om goede resultaten te behalen, stelt het teamleden ook in staat om te weten dat hun mening wordt gewaardeerd en dat zij een belangrijke rol spelen in het project, wat op zijn beurt hun niveau van energie verhoogt. Activiteit #26 van is een voorbeeld van het gebruik van de wijsheid van de massa in projecten.

Voorbeeld: Chief Project Facilitator

Als je een projectmanager bent, hebben de meeste dingen die je doet een faciliterend aspect (of zouden ze dat in ieder geval moeten hebben). Aan de andere kant zou je kunnen opmerken dat de teamleden in het verleden slechte ervaringen hebben gehad met projectmanagers, en dat deze ervaringen van invloed zijn op hun relatie met u: een deel van hun energie wordt besteed aan het analyseren van uw gedrag op potentiële bedreigingen in plaats van u te vertrouwen. In dat geval kunt u uw titel veranderen van projectmanager in Chief Project Facilitator. Dat is immers wat je echt doet in het project.


Wees altijd proactief

Er zit een natuurlijke neiging in ons om reactief te zijn. Het kan ons helpen om onze energie te behouden bij het omgaan met onbelangrijke zaken, of het kan ons betere resultaten geven wanneer we te maken hebben met iets waarin we volledig incompetent zijn. Die situaties zijn anders dan onze projecten - daarin kunnen we immers betere resultaten bereiken door proactief te zijn.

Voorbeeld: Planning

Als u naar een nieuwe locatie wilt rijden en u bent te laat, dan kunt u onmiddellijk beginnen met rijden om “tijd te besparen” en om eventuele problemen op te lossen wanneer deze zich voordoen. De proactieve aanpak is echter om wat tijd te nemen bij de start en uw navigatiesysteem zo in te stellen dat u de snelste route krijgt op basis van het verkeer, en mogelijke ongelukken en blokkades, en daarna te rijden; dat is tijd doorbrengen vóór de uitvoering, om later problemen te voorkomen en zo tijd te besparen op het einde van de rit.

In tegenstelling tot wat sommige mensen over Agile-projecten denken, is planning altijd noodzakelijk - men moet zich wel bewust zijn van de aard en het gewenste niveau van detail in de plannen. Plannen alvorens uit te voeren is een proactieve aanpak.

Denk aan het citaat: “Geef me zes uur de tijd om een boom om te hakken en ik zal de eerste vier uur besteden aan het aanscherpen van de bijl”.

Als deze situatie zich voordoet in een gemakkelijk te voorspellen project, dan kunt u 4 uur besteden aan het slijpen van uw bijl, omdat u er zeker van bent dat u een boom gaat hakken. In een Agile project weet je niet zeker of je een boom gaat hakken, kapotte takken gaat verzamelen, gras gaat oogsten, steenkool gaat hakken, of iets anders. Toch heb je nog steeds een algemene voorbereiding nodig voor al die dingen (bvb. weten waar de dichtstbijzijnde ijzerwinkel is), en je weet dat een specifieke voorbereiding nodig zal zijn (bvb. het slijpen) wanneer je je gaat focussen op een bepaalde oplossing; dat is plannen.

Voorbeeld: Plannen van de planning

Het plannen van de manier waarop we het project gaan uitvoeren is een proactieve aanpak. Deze proactiviteit kan zelfs worden uitgebreid door de manier te plannen waarop we de uitvoering gaan plannen; dat is het management plan-concept van de PMBOK® Guide, Management Strategies in PRINCE2®, en dit wordt ook benaderd in concepten van DSDM®.

Voorbeeld: Doorlopende planning

De werkelijkheid komt zelden overeen met wat we gepland hebben, en dat is oké - maar daarom moeten we onze plannen voortdurend blijven aanpassen om ervoor te zorgen dat ze realistisch en praktisch blijven. Dat moeten we doen zodra aanpassing nodig is, en niet wanneer we in de problemen komen. Ook dat is een proactieve aanpak.

Voorbeeld: Risicomanagement

Het hele concept van risicomanagement is gebaseerd op proactiviteit: wanneer we geconfronteerd worden met onzekere gebeurtenissen, is het niet goed om te wachten, te zien wat er gebeurt en er vervolgens op te reageren. Beter is om op voorhand na te denken over de mogelijkheden en effecten, reacties te overwegen en er iets aan te doen voordat het gebeurt.

Merk op dat wat we in projecten doen serieus is; het gaat soms over het leven van mensen.

Voorbeeld: Definiëren van rollen en verantwoordelijkheden

Je kunt de leden van het projectteam laten werken zonder duidelijke op voorhand bepaalde rollen en verantwoordelijkheden, en vroeg of laat zal er een vorm van taakverdeling ontstaan, maar er zal veel kostbare tijd verloren gaan en deze aanpak garandeert ook geen resultaat. De proactieve aanpak is om in een vroeg stadium de rollen en verantwoordelijkheden te definiëren en deze aan te passen als dat nodig blijkt te zijn. Dit maakt het werken voor iedereen gemakkelijker en iedereen kan zich richten op het realiseren van iets, in plaats van bezig te zijn met het bepalen van wie wat doet.

Het aantal en de verscheidenheid aan rollen is afhankelijk van het type en de omvang van het project; het kan een eenvoudige invulling zijn zoals die in Scrum, iets gematigd zoals in, of iets veelomvattend zoals die in DSDM® en PRINCE2®. Vergeet echter niet dat de rolbeschrijvingen in deze methoden alleen over managementactiviteiten gaan, en dat je ook altijd rolbeschrijvingen voor technische aspecten moet toevoegen.

Voorbeeld: Beschikbare keuzes

Moet je het project voortijdig stopzetten of doorgaan met het project?

Er zijn zelden maar twee keuzes, ook al impliceert de bovenstaande vraag dat. U moet proactief te werk gaan en al uw keuzes in overweging nemen voordat u een beslissing neemt. Misschien kunt u het project herdefiniëren, misschien kunt u het project onderbreken tot er iets duidelijk wordt, of misschien kunt u de projectaanpak veranderen (bv. outsourcing), enz.

Voorbeeld: Kritisch denken

We hebben allemaal veel vooroordelen die ons aan de ene kant helpen om te overleven, maar ons aan de andere kant voor de gek houden en ons daardoor slechte beslissingen laten nemen. Als het gaat over belangrijke beslissingen in het project, is het best om even stil te staan bij alle vooroordelen die onze beslissing zouden kunnen beïnvloeden vooraleer ze problemen veroorzaken.

Als referentie kunt u de lijst van cognitieve fouten in Wikipedia gebruiken: (deze lijst is in het Engels)

Er zijn zelfs besluitvormingskaders die u kunt gebruiken om betere beslissingen te nemen. In het begin is het misschien afleidend en zelfs vervelend om ze te gebruiken, maar al snel went u eraan en profiteert u ervan zonder veel bewuste inspanning.

Voorbeeld: Transparantie

We houden er niet van als het project vertraging oploopt of andere problemen heeft, maar dat betekent niet dat we dat moeten verbergen. U moet transparant zijn en de belanghebbenden op de hoogte brengen, omdat sommige van hen u kunnen helpen, en bovendien zullen zij vroeg of laat op de hoogte zijn van de problemen en de gevolgen ervan. Sommige gevolgen vereisen vroegtijdige acties van de belanghebbenden (bv. het accepteren van negatieve gevolgen).

Voorbeeld: Effectieve communicatie

Het kan in veel gevallen voorkomen dat u rapporten naar belanghebbenden stuurt en dat ze u geen feedback geven. U kan denken dat alles in orde is omdat er geen negatieve feedback is, maar het kan best zijn dat dit niet het geval is. U moet proactief zijn en nagaan of ze het rapport echt hebben gebruikt en of het zijn doel bereikt heeft. Wat u hieruit leert kan u gebruiken om uw manier van communiceren aan te passen. Als u nalaat om dit te controleren, blijft een probleem misschien verborgen, en dit kan later resulteren in ernstige complicaties op een moment dat ze nog maar moeilijk op te lossen zijn.

Voorbeeld: Neem verantwoordelijkheid

Het is gemakkelijk om anderen de schuld te geven van slechte resultaten. Stel bijvoorbeeld dat u wil dat uw organisatie u de volledige bevoegdheid geeft om alles in het project te veranderen zodat alles perfect kan worden georganiseerd zoals het hoort, maar u krijgt die niet en als gevolg daarvan mislukt het project. Dit getuigt niet van proactieve aanpak.

De proactieve aanpak is om verantwoordelijkheid te nemen en alles te doen wat u kan binnen de beperkingen die u zijn opgelegd. U kan niet verwachten dat de organisatie u volledig vertrouwt en u alle mogelijke middelen geeft in de hoop op goede resultaten, vooral wanneer zij al zoveel mislukte projecten heeft meegemaakt. Wat u moet doen is één kleine verbetering maken binnen de gestelde randvoorwaarden, die u dan kan gebruiken om vertrouwen te winnen, samen met een verhoging van de middelen en wat meer tolerantie voor de randvoorwaarden. Dat kan u dan weer gebruiken voor een iets grotere verbetering, en zo kan u doorgaan tot u uw streefdoel bereikt heeft.


Onthoud dat een keten enkel zo sterk is als zijn zwakste schakel

Er zijn verschillende aspecten aan projecten, en die hebben allemaal aandacht nodig; we moeten het project op een holistische manier bekijken. Zich concentreren op een ogenschijnlijk belangrijk domein (bvb. tijd) is niet genoeg, omdat alle domeinen interageren met elkaar. Het project zal dan ook niet goed verlopen tenzij ze allemaal voldoende aandacht krijgen.

Voorbeeld: Het gaat om de deadline!

Laten we zeggen dat je iets aan het bouwen bent voor de Olympische Spelen. Dit project heeft dus een zeer strikte deadline, wat tijdsmanagement erg belangrijk maakt. Maar is dat echt zo? Wat als de kwaliteit zo laag is dat er na een tijdje opnieuw gewerkt moet worden? Dat zou gevolgen hebben op de timing, en we concluderen dus dat niet enkel tijd belangrijk is, maar ook kwaliteit. Stel dat je in een verbouwproject in de projectomschrijving o.a. een mooie afgewerkte tuin hebt staan. Je kan als buffer inbouwen dat als het project in tijdsnood komt, je de tuin kan overslaan en je oppervlakte gewoon kan bedekken met gras. Dit is perfect mogelijk, zolang dat die optie op tijd werd overwogen en dat de voorbereidingen werden getroffen. Dit maakt dat scope ook belangrijk is. Nu hebben we de scope, de tijd en de kwaliteit als centrale aandachtspunten.

Heb je gehoord van dat beroemde voorbeeld waarbij president Kennedy een conciërge in het NASA hoofdkwartier ontmoet en hem vraagt wat hij doet, en hij antwoordt: “Ik help een man op de maan te zetten”? Helpt dat soort mensen in het project ook niet om de deadline te halen?

Naarmate je verder gaat met deze denkoefening, merk je dat elk domein in het project bijdraagt aan tijdmanagement en dat je de deadline niet met een acceptabel niveau van zekerheid kunt halen, tenzij je aandacht besteedt aan alle domeinen.

Voorbeeld: Selectief winkelen

Wanneer mensen geconfronteerd worden met een verscheidenheid aan methoden, beginnen ze soms aspecten te kiezen tussen de verschillende methodologieën (selectief winkelen, of “cherry picking”) en creëren ze een mix van alles wat interessant lijkt uit de verschillende systemen. Dit werkt meestal niet, omdat elementen niet geïsoleerd werken en met elkaar compatibel moeten zijn. Eventuele toevoegingen of wijzigingen aan een systeem moeten vanuit een holistische visie worden gedaan.

Daarom zien we soms tegenstrijdige elementen in verschillende methoden; voor iets dat goed werkt in het ene systeem, werkt het tegenovergestelde goed in een ander systeem. Het element op zich is op zich niet goed of fout.

De veiligste aanpak die je kan gebruiken is om één methodologie voor het project te kiezen, het op maat aan te passen aan jouw project, en er vervolgens voorzichtig nieuwe elementen aan toe te voegen door rekening te houden met de samenhang van het hele systeem.

Voorbeeld: De anti-proces benadering

Eén van de grootste verwezenlijkingen van de Agile-methoden, is dat ze de aandacht hebben gevestigd op de menselijke aspecten. Het Agile Manifesto geeft meer waarde aan individuen en interacties dan aan processen en tools, hoewel dit misschien geen eerlijke vergelijking is. Bijna alle methoden zeggen dat menselijke aspecten belangrijk zijn, maar het echte verschil met Agile-methoden is dat menselijke aspecten daar een vast onderdeel zijn van de processen, in plaats van een eenvoudige suggestie. Het gaat dus niet om een competitie tussen menselijke aspecten en processen, maar eerder om de manier waarop menselijke aspecten in het systeem worden gezien.

Het lijdt geen twijfel dat sommigen proberen de menselijke aspecten te vervangen door meer gebruik te maken van geavanceerde processen, maar dat is geen goede manier van werken. Zelfs het tegenovergestelde bestaat: dat men die processen probeert te vervangen door menselijke aspecten, wat ook niet goed werkt.

Voorbeeld: Dit zijn alle domeinen die u nodig hebt

Als u over de domeinen nadenkt, moet u oppassen dat u er geen van de domeinen mist. Maar welke hebt u dan allemaal nodig? Als u de fundamentele bronnen van informatie raadpleegt, zult u verschillende antwoorden krijgen; en toch is geen van hen de hele waarheid.

PRINCE2® thema’s zijn domeinen, maar dat zijn slechts de domeinen die een sleutelrol spelen in de methodologie. De andere domeinen worden alleen maar geïmpliceerd.

De PMBOK® Guide is geen methodologie en kan dit onderwerp veel beter behandelen met zijn tien kennisgebieden. Dit zijn echter interpretaties van alle domeinen vanuit het perspectief van de PMBOK® Guide op het project, en niet zozeer vanuit een neutraal perspectief (waarmee we niet willen zeggen dat er noodzakelijkerwijs een neutraal perspectief is). Menselijke aspecten krijgen bijvoorbeeld niet veel aandacht in de PMBOK® Guide.

Een goede bron van informatie over de domeinen is ICB. ICB heeft het echter niet over de domeinen, maar over de vaardigheden die nodig zijn in het project. Er is geen één-op-één relatie met de domeinen, maar deze bron is wel een grote hulp om de domeinen te identificeren.

Er is geen lijst van domeinen in NUPP, vooral omdat het een metasysteem is in plaats van een systeem, en ook omdat de categorisering van de domeinen afhankelijk is van het type project en zijn omgeving; een routinematig bouwproject kan bijvoorbeeld een ander perspectief vereisen dan een creatief onderzoeksproject.


Doe niets zonder duidelijk doel

U zou niets mogen doen dat geen duidelijk doel heeft. Stelt u zich twee parallelle werelden voor waar alles hetzelfde is, behalve datgene wat u overweegt te doen: hoe verschillend zouden die werelden zijn? Is het verschil de moeite waard om er aan te werken?

Als je geen duidelijk doel voor ogen hebt en alleen maar iets doet omdat alle anderen het doen, of omdat iedereen zegt dat het belangrijk is om het te doen, dan:

  • kan het zijn dat het in uw geval geen echt voordeel heeft, en dat u er dus niets uit kunt halen; of
  • het kan ook dat het bij u nog steeds potentiële voordelen heeft, maar omdat u het doel niet in gedachten hebt, kan het zijn dat uw manier van werken niet bijdraagt aan het realiseren van die voordelen.

Voorbeeld: Portfolio’s en programma’s

Als u betrokken bent bij het selecteren en het initiëren van projecten, moet u ervoor zorgen dat u zich concentreert op de toegevoegde waarde en de problemen die moeten worden opgelost in plaats van op het product dat die dingen gaat realiseren. Het klassieke voorbeeld is de fabrikant van liften die vroeger klachten ontving over de snelheid van hun liften, en zo meerdere projecten had uitgevoerd om de snelheid te verhogen, zonder volledig succes. Dat ging door tot ze besloten om zich te concentreren op het probleem (de verveling of het ongemak van mensen) in plaats van op de “natuurlijke” oplossing (snellere liften). Als resultaat werden spiegels aan de liften toegevoegd, en het probleem werd eenvoudig en goedkoop opgelost.

Vergeet niet dat projectmanagement vooral gaat over het juist uitvoeren van de dingen, terwijl portfoliomanagement gaat over het uitvoeren van de juiste dingen. Het maakt niet uit hoe goed u uw projecten uitvoert; het zal niet goed werken als u de verkeerde projecten kiest. Het is allemaal een kwestie van het hebben van een duidelijk doel.

Voorbeeld: Het project als geheel

De flexibiliteit van het product verschilt per project. In sommige IT-ontwikkelingsprojecten is het product volledig flexibel en hangt de uiteindelijke vorm af van de feedback die de incrementele groei van het product tijdens het project zal genereren, wat een adaptieve (Agile) aanpak vereist. Dit is in de praktijk een combinatie van de portfolio-, de programma- en de projectlagen, en vereist maximale aandacht voor het uiteindelijke doel. Het is een goed idee om het doel te documenteren en toegankelijk te houden; het is één van de doelen van de “productvisie”, zoals gebruikt in sommige Scrum-projecten. De aandacht voor de bedrijfswaarde in Agile projecten is hun manier om te zorgen voor afstemming met het doel.

In andere soorten projecten, waar het product relatief vast ligt en er andere mechanismen zijn om ervoor te zorgen dat het uiteindelijke product aan het doel voldoet, is het mogelijk voor de projectteamleden om een groot deel van hun focus te verschuiven van het doel naar het product (vandaar het “focus op producten” principe van PRINCE2®). Maar er is nog steeds minimale aandacht nodig voor het doel om ervoor te zorgen dat wat gebouwd wordt aan het doel voldoet. Dit kan worden gedaan door het vergelijken van de geplande voordelen met de verwachtte voordelen (vandaar het principe van de “continued business justification” en het “business case” thema in PRINCE2®).

Wanneer een project voor een externe klant wordt uitgevoerd, heeft de klant voor zichzelf een doel voor het project, en heeft uw bedrijf een ander doel. U moet beide begrijpen en gebruiken om echt te slagen.

Voorbeeld: Monitoring van het project

Focussen op het uiteindelijke doel is noodzakelijk, maar dat doel kan te abstract zijn voor veel van de dagelijkse toepassingen. Daarom is een hiërarchie van factoren nodig om het praktischer te maken. Eerst worden de rechtvaardiging en de voordelen van het project gedefinieerd op basis van het uiteindelijke doel, en dan heb je expliciete en impliciete doelstellingen voor projectvariabelen (bv. tijd, kosten en kwaliteit) om aan de rechtvaardiging te voldoen, die ook op hun beurt aan het uiteindelijke doel zullen voldoen. Dit zijn doelen op lager niveau die nuttig zijn voor veel van onze dagelijkse taken.

Als het aankomt op monitoring, zal de low-level monitoring van het project worden gedaan met behulp van het laagste niveau van variabelen, omdat het niet altijd mogelijk is om het uiteindelijke doel te volgen. In dit geval moet u nog steeds de doelen voor ogen houden: wat is het doel van monitoring?

Een normaal en aanvaardbaar antwoord is om te bepalen of we op schema liggen, en zo niet, om een bepaalde reactie op gang te brengen die ons weer op schema brengt of de doelstellingen bijstelt en nagaat of het uiteindelijke doel nog steeds kan worden bereikt. Onze metingen moeten daarom in staat zijn om te helpen met dit lage doel, en de juiste metingen zijn voorspellingen voor de variabelen bij de voltooiing; bijvoorbeeld, wanneer zouden we het project kunnen voltooien? Hoeveel geld zouden we nodig hebben om het project af te ronden?

Alle andere metingen, zoals de geplande en werkelijke waarden tot nu toe, zijn slechts tussentijdse waarden die u nodig heeft om de voorspellingen te berekenen, niet de uiteindelijke waarden die u gebruikt voor managementdoeleinden.

Voorbeeld: Documenten

Welke aanpak je ook gebruikt bij de ontwikkeling van het project, planning is altijd noodzakelijk. De belangrijke vraag is de mate van detail in elk type plan. Als er niet voldoende detail in het plan zit, zal het plan niet genoeg kunnen bijdragen en zal de uitvoering van het project gebaseerd zijn op ad hoc beslissingen in plaats van op geïntegreerde, holistische beslissingen. Aan de andere kant proberen veel mensen voorzichtig te zijn en te veel details toe te voegen, wat hun plan te moeilijk maakt om het voor te bereiden en te onderhouden, en te star voor de onzekerheden van het project. Het gevolg is dat het plan onrealistisch en nutteloos wordt.

De beste manier om te beslissen over de mate van detaillering is om voor elk element in het plan een doel voor ogen te hebben. Als u bijvoorbeeld overweegt om middelen aan het plan toe te voegen, moet u er een doel voor hebben: hoe ga je ze gebruiken? Hoe zullen ze het project helpen? Hoeveel moeite zal het kosten? En is het de moeite waard?

Soms gaat het erom te beslissen of je een bepaald element in je plannen wilt hebben, soms gaat het om de manier waarop je iets wilt plannen of voorbereiden. Of het nu gaat om een business case, een projectcharter of een rapport: u moet zich nog steeds afvragen waarom u dat document voorbereidt en hoe dit het project kan helpen.

Het zoeken naar een “sjabloon” is het tegenovergestelde van iets doen op basis van een doel.

Voorbeeld: Statusrapporten

Het is gebruikelijk om in veel projecten lange statusrapporten te hebben. Op basis van deze NUP moeten we ons afvragen wat het doel van zo’n verslag is en hoe we dat doel kunnen bereiken, ongeacht wat de meeste andere mensen doen.

Dit kan er in veel gevallen toe leiden dat we zeer eenvoudige rapporten van één pagina opstellen die door de belanghebbenden echt gelezen en begrepen worden in plaats van lange rapporten. Dit is aandacht besteden aan het doel.

Als u echter rapporten van één pagina voorbereidt, kunnen sommige mensen bezwaar maken tegen u en denken dat u geen “goed” monitoringsysteem hebt. In de praktijk creëert dit een tweede doel voor u (naast het eerste doel, namelijk belanghebbenden helpen de status van het project te begrijpen), en om dat te bevredigen, kunt u eenvoudigweg een tweede type rapport maken dat erg lang is. U zult dat echter niet vermengen met het eerste rapport, omdat deze twee doelen niet hetzelfde zijn.

Voorbeeld: Business case en projectcharter

Het opstellen van documenten zoals een business case en een project charter is voor de meeste mensen meestal een saaie, vruchteloze, bureaucratische noodzaak, terwijl deze documenten allemaal geldige doelen hebben die voor de meeste projecten gelden. Als u een “sjabloon” probeert te vinden en in te vullen, is het werk gewoon verspild; wanneer u daarentegen de echte doelstellingen van die documenten controleert, kijkt of en hoe ze nuttig kunnen zijn in uw project, en vervolgens de documenten voorbereidt op eender welke manier die u verkeur uitgaat, en u tracht op deze manier aan de doelstellingen van de oefening te voldoen - zo verkrijgt u behoorlijke en nuttige documenten.

Terwijl u nadenkt over de manier waarop u de documenten kunt voorbereiden om aan hun doelstellingen te voldoen, denkt u misschien niet aan elk scenario en mist u misschien iets. Om dat te voorkomen, kunt u controleren wat bronnen zoals PRINCE2®, PMBOK® Guide, en DSDM® suggereren, en deze suggesties kan u vervolgens evalueren op basis van uw doelstellingen.

Voorbeeld: Na afloop van het project

Hoewel het project een specifiek doel heeft, en we het halen van dat doel gedurende het hele project mogen beoordelen, wordt de realisatie van het doel voornamelijk geëvalueerd op basis van de voorspellingen die tijdens het project worden gedaan. We mogen de evaluatie na afloop van het project echter niet vergeten. Het is belangrijk om de realisatie van de doelen na het project te controleren, omdat

  • we dan kunnen zien hoe de uiteindelijke doelen worden bereikt en daarvan kunnen leren voor toekomstige projecten, en
  • soms de doelen alleen bereikt worden als we na de voltooiing van het project nog enkele bijkomende taken uitvoeren, en het begrip van de noodzaak van die extra taken vraagt om monitoring.

Die monitoring na afloop van het project is een noodzakelijke stap bij een doelgerichte aanpak. Dit is vooral de verantwoordelijkheid van programma- en portfoliomanagementsystemen, en omdat de meeste bedrijven niet over dergelijke managementlagen beschikken, wordt deze stap meestal verwaarloosd. Daarom voegen methoden zoals en DSDM® deze stap toe aan hun projectmanagementmethoden.

Voorbeeld: Eenvoud

De wereld is complex en chaotisch, maar onze modellen benaderen delen van de wereld op een abstracte manier, en kunnen dus eenvoudig zijn. Daarenboven werken eenvoudige systemen meestal beter, omdat we ons op het hoofdidee kunnen concentreren.

Velen van ons proberen betere resultaten te bereiken door complexiteit aan onze systemen toe te voegen, in de hoop dat het zal overeenkomen met de complexiteit van de wereld, ook al maakt dit het systeem in de praktijk moeilijk werkbaar en blokkeert het ons meestal om aan het doel te voldoen.

Voorbeeld: Maatwerk

Een stuk software voor het streamen van muziek vereist heel andere eigenschappen dan een stuk software dat gebruikt wordt voor apparatuur in een ziekenhuis of een vliegtuig waar het leven van mensen van afhangt, of een stuk software dat gebruikt wordt in een satelliet waar het vele jaren zou moeten werken zonder te crashen, en ze zijn allemaal verschillend van het bouwen van een zomervilla, een brandweerkazerne, en een verwerkingsfabriek.

Wanneer u de doelstellingen in gedachten heeft, zal u beter begrijpen hoe u de systemen en de documentatie voor verschillende projecten kunt aanpassen.


Gebruik herhaalbare elementen

Een ad hoc aanpak van het project kost te veel energie en middelen en loopt altijd het risico dat een aantal noodzakelijke elementen ontbreken. De beste manier om te vereenvoudigen is het gebruik van herhaalbare elementen, bij voorkeur in herhaalbare cycli.

Voorbeeld: Kwaliteitschecklists

Een checklist is een eenvoudig voorbeeld van een potentieel herhaalbaar element dat veel mensen in hun persoonlijke en professionele leven gebruiken. Neem bijvoorbeeld de kwaliteitscriteria van een eindproduct:

  • Eerst kunt u een checklist van alle criteria maken, een vorm van planning.
  • Wat NUP6 aanbeveelt is om te proberen het te veralgemenen: zijn er andere, vergelijkbare eindproducten in het project? Bereid in dat geval een algemene kwaliteitchecklist voor die categorie van eindproducten voor en gebruik die voor al die producten. Als er enkele variaties zijn, houd dan de algemene lijst bij en voeg een paar extra items toe voor de specifieke eindproducten. Nu heb je herhaalbare checklists.
  • Als u eenmaal algemene checklists hebt opgesteld voor verschillende types eindproducten, kunt u elementen vinden die zich onder hen herhalen, wat een virtuele overlappende ‘ouder’-categorie voor hen suggereert. In dat geval kunt u, in plaats van de items van al die algemene checklists te herhalen, deze uitpakken en ze in een ouderchecklist plaatsen. Uiteindelijk heb je waarschijnlijk één algemene checklist voor het hele project. Scrum’s “definition of done” is een voorbeeld van het gebruik van checklists op projectniveau voor kwaliteit (tussen eventueel nog andere checklists). Door dit te doen, zal elk eindproduct behoren tot een hiërarchie van categorieën en moet het voldoen aan de items die voorkomen in de checklists van alle categorieën in hun keten.

Hierdoor wordt een item in de ouderchecklist herhaalbaar voor alle deliverables eronder, wat tijd en energie bespaart in planning en uitvoering.

Belangrijker nog: als u dit eenmaal voor één project doet, kunt u het op maat maken en gebruiken voor alle soortgelijke projecten in de toekomst, wat een herhaalbare vorm van planning is voor meerdere projecten.

Voorbeeld: Processen en workflows

Sommige deliverables, of eraan gekoppelde doelen, hebben bepaalde stappen nodig die gestandaardiseerd en herhaalbaar kunnen worden. Als de deliverables bijvoorbeeld individueel moeten worden ontworpen en goedgekeurd, kunt u een eenvoudige workflow voorbereiden die hiervoor alle stappen, de betrokken mensen en de geschatte duur duidelijk maakt, zodat veel problemen worden vermeden. U moet er echter op letten dat u de workflows en processen niet te ingewikkeld maakt of overdocumenteert, omdat dit negatieve implicaties zal hebben. Alle mensen die betrokken zijn bij het project zouden de workflows en processen moeten zien als iets dat hun werk ondersteunt en alles gemakkelijker maakt voor hen, in plaats van als bureaucratische documentatie die hun echte werk blokkeert.

Agile projecten hebben herhaalbare elementen in hun iteratieve ontwikkelingsaanpak, waarbij bepaalde soorten ontwikkelingsactiviteiten worden herhaald voor elke functie; bijv. de gebruikelijke dagelijkse routine in XP (eXtreme Programming): het koppelen, het kiezen van een item, het ontwerpen op een whiteboard, het bouwen van de testscripts en de code, het integreren van de code, enz.

Naast de herhaalbare workflows die gebruikt kunnen worden voor technische activiteiten, kunt u ook herhaalbare elementen hebben voor de project management activiteiten. De processen in de PMBOK® Guide, PRINCE2® en DSDM®, de activiteiten in en de evenementen in Scrum zijn voorbeelden van dit concept.

Voorbeeld: Cycli

Het is nuttig om herhaalbare elementen te hebben voor het beheer van het project. Men kan nog meer vereenvoudigen door deze in herhaalbare cycli te plaatsen. Deze cycli maken de dagelijkse activiteiten van mensen die betrokken zijn bij het beheer en de leiding van het project een stuk gemakkelijker. Voorbeelden van dit concept zijn cycli van procesgroepen bij gebruik in een project met meerdere fasen in de PMBOK® Guide; stadia in PRINCE2®; dagelijkse, wekelijkse en maandelijkse cycli in; iteraties en tijdsblokken in DSDM®; en Sprints in Scrum.

Kortere cycli zijn gemakkelijker te begrijpen en te gebruiken dan langere cycli, bijvoorbeeld Sprints in Scrum in tegenstelling tot de fasen volgens de PMBOK® Guide. Te korte cycli kunnen echter niet voldoende zijn om bepaalde soorten projecten te ondersteunen. Een oplossing kan het gebruik van meerdere cycli zijn, zoals DSDM®’s gebruik van korte tijdblok-cycli in combinatie met langere iteratie-cycli, of het gebruik van’ van dag-, week- en maandcycli.

Voorbeeld: Methoden

Het gebruik van een methodologie of een framework voor het uitvoeren van een project is een ander voorbeeld van het gebruik van herhaalbare elementen. Dit kan een bestaand systeem zijn zoals PRINCE2®,, DSDM® of Scrum, of een systeem dat u zelf heeft aangepast of gebouwd. Doorgaans is het een beter idee om te beginnen met één van de bestaande methoden en deze aan te passen aan uw behoeften, dan om het vanaf nul op te bouwen.

Elk herhaalbaar element is abstract en moet worden aangepast om het te doen passen in de echte wereld. Er bestaat echter een spectrum van abstractie en behoefte aan maatwerk: kleine, relatief concrete kwaliteitschecklists staan aan de ene kant van het spectrum met de minste abstractie en behoefte aan maatwerk, terwijl aan de andere kant de methodologieën het meest moeten worden aangepast. U moet altijd rekening houden met de noodzaak van maatwerk, anders zal het herhaalbare element niet goed aansluiten bij uw behoeften.


Les Principes Quasi Universels de Projets (NUPP - Nearly Universal Principles of Projects) sont ceux que nous avons intérêt à suivre pour tout projet, quelles que soient les méthodologies et les approches que nous utilisons, pour maximiser nos probabilités de succès.

Chaque livre et méthode de gestion de projets prend en compte certains de ces principes quasi universels (NUP - Nearly Universal Principles), cependant :

  • Ils ne sont pas traités dans leur ensemble, or ce serait utile que les praticiens considèrent tous les principes quasi universels (NUP - Nearly Universal Principles) au lieu de quelques-uns,
  • les principes sous-jacents la gestion de projet ne sont généralement pas assez clairs dans les livres et la plupart des professionnels en gestion de projets sont tellement focalisés sur les aspects pratiques qu’ils oublient les principes et adoptent des pratiques qui ne leur sont pas compatibles.

Les Principes Quasi Universels de Projets (NUPP - Nearly Universal Principles of Projects) sont compatibles avec les systèmes, ressources et méthodologies majeures tels que PRINCE2®, le guide PMBOK®,, PM², DSDM®, XP et Scrum. Bien qu’ils ne soient pas compatibles avec certaines interprétations de ces systèmes, les NUPP tentent d’encourager les praticiens à reconsidérer leurs interprétations. Les principes quasi universels (NUP - Nearly Universal Principles) sont :


Préférer les résultats et la vérité aux affiliations

Nous avons naturellement un besoin d’appartenance à des groupes. Il arrive que cette appartenance prenne des formes qui dépassent son cadre de base. Ainsi de fortes affiliations peuvent naître de ce fait et causer des problèmes. En effet, nous pourrions étouffer l’éclosion de notre potentiel à cause des affiliations, alors qu’en évitant de limiter notre identité et nos préférences à certains groupes nous pouvons devenir des experts plus professionnels et plus efficaces.

Exemple : La methodologie Agile vs Predictive

Des personnes très motivées ont eu le courage d’essayer des approches de développement adaptatif en développement informatique lorsque la norme consistait à utiliser des approches prédictives. Le groupe décida d’appeler leur méthodologie Agile. C’était une excellente initiative qui prouva qu’il ne fallait pas limiter ses choix à ce qui semblait être nécessaire. Il existe toujours de nombreuses personnes enthousiastes et orientées résultats dans la communauté Agile, mais malheureusement, certains membres de cette communauté transforment Agile en culte et prennent en adversité toute autre approche. Cela pose problèmes pour plusieurs raisons, notamment :

  • Cette attitude les empêche d’apprendre de qui que ce soit en dehors de leur groupe
  • les autres professionnels en gestion de projets sont retissant à apprendre d’eux
  • l’appartenance au groupe devient plus importante que le réel objectif, ce qui empêche plusieurs de leurs membres d’apprendre le véritable sens de l’Agilité.

Ce problème peut être maitrisé, voire supprimé :

en utilisant «Agile» uniquement comme un label faisant référence à une approche de développement plutôt qu’à une communauté avec des membres, en ayant des personnes qui se considèrent comme des créateurs, des porteurs de solutions et des leaders qui considèrent Agile comme l’une des méthodologies efficaces qui ont amélioré la gestion de projet de développement informatique, pas comme leur identité.

Il n’existe pas de guerre de méthodologies Agile-Prédictive pour un vrai professionnel.

Exemple : PRINCE2® vs. Guide PMBOK®

De nombreux professionnels de la communauté s’associent à PRINCE2® ou à PMBOK® (généralement en raison de leur situation géographique) et ne connaissent pas l’autre. Nous avons tous le droit d’avoir des préférences vis à vis de certaines bases de connaissances. Ceci ne fait pas d’elles notre identité. Mieux, nous devons nous familiariser avec toutes les bases de connaissances pour élargir notre perspective et nos choix.

Le vrai professionnel est ouvert à la connaissance sans discrimination, il la recherche, l’acquiert, en fait usage partout où cela est requis, sans pour autant s’affilier.

Exemple : La Formation continue

Les affiliations satisfont l’individu à travers le sentiment d’appartenance et ne le poussent pas acquérir de nouvelles connaissances. Dans certains cas, les affiliations le découragent même d’apprendre de peur de les perdre. Quand vous êtes libre, un expert sans affiliations, vous avez besoin de vous étoffer avec la formation : avec la formation continue.

Nos certitudes d’aujourd’hui sont simplement notre meilleure compréhension du moment, qui doit être améliorée au fur et à mesure que nous evoluons. Elles ne sont pas la vérité. Si nos idées sont exactement les mêmes que ce qu’elles étaient il y a quelques années alors nous avons quelques raisons de nous inquiéter. C’est même le cas pour les Principes Quasi Universels de Projets (NUPP - Nearly Universal Principles of Projects) : si vous revenez après quelques années et que vous voyez exactement la même chose, vous devriez devenir suspicieux.

Exemple : L’ouverture d’esprit

Lorsque vous vous opposez à une personne, assurez-vous que l’objection vise l’idée, pas la personne. Cela aide à prévenir beaucoup de tensions. D’autre part, quand quelqu’un vous oppose, essayez de ne pas interpréter cela comme une guerre contre vous, mais comme un débat d’idée, et restez ouvert à cela. N’écoutez pas pour répondre, écoutez pour comprendre, et travaillez avec l’autre personne pour améliorer l’idée.

Bien que certaines personnes puissent vous cibler intentionnellement au lieu de l’idée, aidez-les à se concentrer sur l’idée plutôt que sur vous avant de poursuivre et essayez de préservez cet esprit tout au long de la conversation.


Préserver et optimiser énergie et ressources

Les ressources disponibles pour le projet sont limitées, de même que l’énergie mentale nécessaire pour prendre de bonnes décisions. Vous devez préserver et optimiser cette ressource (l’énergie mentale) pour vous-même et le projet et aider les autres membres de l’équipe à faire de même.

Exemple : La loi des 80/20

Une portion importante des bénéfices possibles en matière de gestion de projet est obtenue avec un minimum d’effort. Dans la plupart des cas, cibler 100% des bénéfices possibles est très coûteux et injustifiable. Vous devez tenir compte de cette règle dans tout ce que vous faites et encourager les autres à faire de même.

Exemple : La fatigue décisionnelle

Nous utilisons une source d’énergie mentale unique pour prendre toutes sortes de décisions et exprimer notre volonté. Si vous utilisez une portion importante de cette source pour des décisions non strictement nécessaire ou inutiles, vous aurez moins d’énergie pour les décisions importantes, ce qui peut entraîner des contreperformances. C’est l’une des raisons pour lesquelles vous devriez éviter la micro-gestion (le principe de « délégation » de PRINCE2®).

Les désaccords sur les idées peuvent être utiles, mais les conflits de personnes nuisent généralement au projet, ce qui aboutit à l’épuisement de l’énergie mentale des membres de l’équipe. Si vous voyez un tel conflit, vous devez faire de votre mieux pour en comprendre la cause et la résoudre.

Exemple : prenez soin de vous !

Les décisions que vous prenez et la volonté que vous exprimez utilisent votre source d’énergie mentale. D’autre part, cette source est remplie d’énergie lorsque vous dormez et mangez correctement. Alors, prenez bien soin de vous : assurez-vous de dormir suffisamment, de vous reposer et de bien manger. Si vous avez des problèmes à dormir, vous n’avez pas à vous en occuper seul ; de nombreux spécialistes peuvent vous aider à résoudre ce problème plus facilement. L’activité physique peut également aider avec cette source d’énergie, mais les études ne sont pas encore concluantes à ce sujet.

Essayez d’encourager les membres de l’équipe à faire de même. Tout d’abord, assurez-vous qu’ils travaillent à un rythme soutenable et sans trop d’heures supplémentaires. Ensuite, dans la mesure du possible, essayez de proposer des aliments sains, des collations et des boissons énergiques pendant les heures de travail.

Exemple : l’équilibre vie professionnelle-vie privée

En général nous aimons notre travail, mais le travail à lui tout seul n’offre pas une vie équilibrée et heureuse. Autant vous êtes performant au travail, autant vous devriez planifier et mettre en œuvre des idées dans votre vie personnelle pour rester joyeux et heureux. Etant heureux, vous pouvez avoir plus de succès au travail. Essayez d’encourager les membres de votre équipe à faire de même dans la mesure du possible.

Exemple : la motivation

La motivation est un concept complexe. Il existe des livres intéressants et utiles sur le sujet, mais aussi de nombreuses approches non scientifiques. Néanmoins, vous devriez comprendre ce concept et l’utiliser en permanence, car cela augmente l’énergie mentale de l’équipe et la possibilité d’obtenir de bons résultats dans le projet. La motivation peut être aussi simple que de faire savoir aux gens que vous remarquez leurs bonnes performances par un gentil sourire ou un simple « merci ». Cependant, soyez prudent, car bon nombre des méthodes de motivation courantes ont un effet négatif ; par exemple, une petite récompense financière.

Exemple : la collaboration et le travail d’équipe

Les personnes qui collaborent ont généralement la force d’obtenir de bons résultats, mais plus important encore, notez que les humains sont êtres sociaux et aiment faire partie d’un groupe. Si vous pouvez supprimer les aspects négatifs du travail d’équipe et créer un environnement agréable, les membres de l’équipe seront plus heureux dans le projet. Soyez prudent, cependant, car les gens sont différents et certains ont besoin de plus de temps de détente, de concentration et de solitude que d’autres. Il s’agit généralement de trouver le bon équilibre.

Exemple : la culture de l’esprit d’équipe

Les différents acteurs du projet ont tendance à créer ou considérer des sous-groupes et ceci génère des tensions avec d’autres groupes ; par exemple, les personnes responsables des aspects financiers et de gestion du projet contre les personnes qui le réalisent techniquement. Ces tensions font perdre beaucoup d’énergie dans les deux camps, et c’est l’une des raisons pour lesquelles nous devrions essayer de créer une culture reposant sur l’esprit d’équipe, une seule équipe dans laquelle tout le monde travaille pour le même objectif.

Exemple : la sagesse de la foule

Lorsqu’un groupe de personnes de cultures diverses se réunit et travaille dans un environnement adéquat, il est possible d’obtenir de très bons résultats, de très bonnes idées et des solutions parfois meilleures à celles émanant d’un seul expert.

Si cette option est à votre portée, vous pouvez l’utiliser régulièrement en demandant aux membres de l’équipe de vous aider à résoudre des problèmes difficiles liés au projet. A delà de l’obtention de bons résultats, cette approche permet également aux membres de l’équipe de savoir que leurs opinions sont prises en compte et qu’ils jouent un rôle important dans le projet, ce qui booste leur énergie. L’activité n°26 de est un exemple d’application de la sagesse du groupe dans les projets.

Exemple : animateur en chef du projet

Si vous êtes chef de projet, la plupart de vos activités ont un caractère de facilitation (ou du moins devraient l’avoir). D’autre part, vous constaterez peut-être que les membres de l’équipe ont eu de mauvaises expériences avec des chefs de projets dans le passé, et que ces expériences ont une incidence sur leur relation avec vous : une partie de leur énergie est consacrée à l’analyse de votre comportement pour détecter les menaces potentielles au lieu de vous faire confiance. Dans ce cas, vous pouvez changer votre titre de chef de projet en animateur en chef du projet. Après tout, c’est ce que vous faites en réalité dans le projet.


Soyer toujours proactif

Nous avons une tendance naturelle à être réactifs. Cela peut nous aider à préserver notre énergie dans des domaines sans importance, ou à obtenir de bons résultats lorsque nous opérons dans un domaine où nous n’avons aucun savoir-faire. Ces situations sont différentes de nos projets et pour obtenir de bons résultats ici il faudra être proactif.

Exemple : planification

Si vous souhaitez vous rendre à un endroit pour la première fois et que vous êtes en retard, vous pouvez commencer à conduire immédiatement pour « gagner du temps » et gérer les problèmes éventuels au fur et à mesure qu’ils surviennent. L’approche proactive consiste à prendre un peu de temps et à configurer votre « GPS » pour vous donner l’itinéraire le plus rapide en fonction du trafic, des accidents et blocages possibles, puis démarrer ; c’est cela se donner le temps de préparation avant l’exécution, pour éviter des problèmes plus tard et gagner du temps à la fin.

Contrairement à ce que certains pensent des projets Agile, la planification est toujours nécessaire ; seuls le type et le niveau de détail des plans diffèrent d’une méthodologie à une autre. Planifier avant l’exécution est une approche proactive.

Rappelez-vous la citation : « donnez-moi six heures pour abattre un arbre et je passerai les quatre premières à affûter la hache. »

S’il s’agit d’un projet prédictif, vous pouvez passer 4 heures à affûter votre hache, car vous êtes sûr de vouloir abattre un arbre. Dans un projet Agile, vous ne savez pas si vous allez abattre un arbre, récupérer des branches cassées, récolter du gazon, extraire du charbon ou autre chose. Néanmoins, vous devez toujours vous y préparer de façon générale (savoir où se trouve la quincaillerie la plus proche) et de façon plus spécifique (affûter votre hache) lorsque vous allez vous concentrer sur une solution donnée. c’est cela la planification.

Exemple : planifier la planification

Planifier la manière dont nous allons exécuter le projet est une approche proactive. Cette proactivité peut même être étendue en planifiant la manière dont nous allons planifier l’exécution ; c’est le concept de plan de gestion du Guide PMBOK®, les stratégies de gestion de PRINCE2® et les approches de DSDM®.

Exemple : planification continue

La réalité correspond rarement à ce que nous avons prévu, et il faut s’y attendre. Cependant, nous devons continuellement adapter nos plans pour nous assurer qu’ils restent réalistes et pratiques. Nous devrions le faire dès que l’adaptation est requise, non pas lorsque surviennent des problèmes ; ceci est une approche proactive.

Exemple : gestion du risque

Toute la notion de gestion du risque repose sur une approche proactive : face à des événements incertains, au lieu d’attendre de voir ce qui se passe et d’y réagir, nous réfléchissons aux possibilités et aux impacts, examinons les réponses et, si possible agissons par anticipation avant que l’événement ne se produise.

Notez que ce que nous faisons dans les projets est très sérieux ; c’est parfois la vie des humains qui est en jeu.

Exemple : définir les rôles et les responsabilités

Vous pouvez choisir de laisser les membres de l’équipe de projet travailler sans clairement définir leurs rôles et responsabilités. Plus tard, une certaine forme de rôle et de responsabilité se formera, mais c’est trop cher payer et peut ne pas fonctionner. L’approche proactive consiste à les définir tôt à la toute première phase du projet et à les adapter si nécessaire. Cela facilite le travail de tous, et chacun peut se concentrer sur la réalisation de l’idée, du service ou produit, au lieu de décider qui fait quoi.

Le nombre et la variété des rôles dépendent du type et de la taille du projet. il peut s’agir d’une définition simple telle que celle de Scrum, quelque chose de modéré tel que celui de ou complète, comme celles de DSDM® et PRINCE2®. Cependant, n’oubliez pas que les descriptions de rôle dans ces méthodes ne concernent que les activités de gestion, et vous devez toujours ajouter des descriptions de rôle pour les aspects techniques.

Exemple : clôturer prématurément ou poursuivre le projet

Devez-vous clôturer le projet prématurément ou le poursuivre ?

Il n’y a rarement que deux possibilités, même si c’est ce que sous-entend la question. Vous devez adopter une approche proactive et analyser toutes vos options avant de prendre une décision. Peut-être que vous pouvez modifier le cahier de charges du projet ; Peut-être que vous pouvez faire une pause jusqu’à ce que quelque chose devienne clair pour évoluer ; vous pouvez peut-être changer l’approche du projet (par exemple, choisir une tierce partie pour continuer le projet), etc.

Exemple : La Pensée critique

Nous avons tous beaucoup de préjugés qui nous aident à survivre d’une part, et à prendre de mauvaises décisions d’autre part. Lorsqu’il s’agit de prendre des décisions importantes dans le cadre du projet, il est préférable de se donner le temps de prendre en compte tous les préjugés qui peuvent avoir une incidence sur notre décision avant qu’ils ne posent problème.

À titre de référence, vous pouvez utiliser la liste des Biais cognitifs de Wikipedia :

Il existe même des cadres décisionnels que vous pouvez utiliser pour améliorer votre processus de prise de décisions. Au début, ils peuvent être déroutant et même agaçant de les utiliser, mais vous vous habituerez vite à eux et les appliquerez sans effort avec le temps.

Exemple : La transparence

Nous aimons éviter d’être en retard ou d’avoir quelque problème que ce soit dans le projet, mais cela ne signifie pas que nous devrions cacher ces cas s’ils surviennent. Soyez transparent et informez les parties prenantes, car certaines d’entre elles pourront peut-être vous aider. De toutes les façons, elles finiront par découvrir les problèmes et leurs conséquences tôt ou tard, et certaines d’entre elles devront agir vite (par exemple, accepter la conséquence négative).

Exemple : communiquer efficacement

Il arrive souvent que vous envoyez des rapports aux parties prenantes sans que celles-ci ne vous fassent part de leurs commentaires. Vous pensez peut-être que tout va bien juste parce qu’il n’y a pas de retour négatif. Vous devez être proactif et vérifier s’ils ont vraiment fait usage du rapport et si celui-ci a été utile, puis recueillir les remarques pour ajuster votre méthode de communication. Si vous sous estimez la nécessité de vous assurer que les parties prenantes utilisent vos rapports, cela risque de poser de graves problèmes de communication qu’il sera trop difficile de les résoudre plus tard.

Exemple : assumer ses responsabilités

Il est facile de faire porter aux autres la responsabilité des mauvais résultats. Par exemple, vous voudriez que votre organisation vous donne les pleins pouvoirs de changer tout le projet et de le faire parfaitement, mais ce n’est pas le cas ; par conséquent le projet échoue. Ceci n’est pas une approche proactive.

L’approche proactive consiste à assumer ses responsabilités et à faire tout ce qui est en son pouvoir dans les limites imposées. Vous ne pouvez pas vous attendre à ce que l’organisation vous fasse pleinement confiance et vous donne tout dans l’espoir d’obtenir de bons résultats, surtout lorsque la tendance générale d’échec de projets est à la hausse. Ce que vous devez faire est d’apporter une petite amélioration aux contraintes définies, l’utiliser pour gagner un peu de confiance de la part des parties prenantes, un peu plus de ressources et un peu plus de tolérance pour les contraintes, l’utiliser ensuite pour un impact positif plus visible, ainsi de suite jusqu’à ce que vous atteigniez l’objectif ultime.


Rappelez-vous qu’une chaîne est aussi forte que son maillon le plus faible

Il existe différents domaines dans les projets et ils nécessitent tous une attention particulière. Nous devons avoir une perspective holistique du projet. Faire attention à un domaine apparemment important (par exemple, le temps) ne suffit pas, car tous les domaines interagissent et ne fonctionnent correctement que s’ils reçoivent tous suffisamment d’attention.

Exemple : tout dépend de la date limite !

Disons que vous construisez quelque chose pour les Jeux Olympiques. Les délais sont très critiques, ce qui rend la gestion du temps très importante. N’est-ce pas ? Que se passe-t-il si la qualité du rendu est si mauvaise que cela entraîne un travail supplémentaire pour les corrections ? cela aurait un impact sur le temps. Donc la qualité est tout aussi importante que le temps. Vous avez prévu un jardin très élaboré dans la définition originale du projet, mais vous savez que s’il n’y a pas assez de temps, vous pouvez le simplifier en recouvrant la surface de gazon, tant que vous avez envisagé cette possibilité à temps et que vous vous y êtes préparé. La gestion du cahier des charges est donc également importante. Nous avons ainsi les domaines du cahier des charges, du temps et de la qualité au centre de toutes les attentions.

Avez-vous entendu parler de cette célèbre anecdote dans laquelle le président Kennedy a rencontré un concierge de la NASA et lui a demandé ce qu’il faisait, et il a répondu : « J’aide à faire poser un homme sur la lune » ? La participation de ce type de personnes au projet ne permet-elle pas de respecter les délais ?

Au fur et à mesure, vous constaterez que chaque domaine du projet contribue à la gestion du temps, et vous ne pouvez pas respecter l’échéance avec une certitude acceptable si vous ne prêtez pas attention à tous les domaines.

Exemple : Le picorage

Lorsqu’exposés à diverses méthodologies, parfois nous commençons à sélectionner les éléments de part et d’autre et créons un mélange de tout ce qui semble intéressant à partir de systèmes différents. Cela ne marche généralement pas, car les éléments ne fonctionnent pas de manière isolée et doivent être compatibles les uns avec les autres. Tout ajout ou changement à un système doit être effectué avec une vue holistique.

C’est pourquoi nous constatons parfois des éléments contradictoires dans des méthodologies différentes ; quelque chose fonctionne bien dans un système, et son contraire fonctionne bien dans l’autre système. Pris isolément, cet élément n’est ni vrai ni faux en soi.

L’approche la plus sûre consiste à sélectionner une méthodologie pour le projet, à l’adapter, puis à y ajouter prudemment de nouveaux éléments en tenant compte de la cohérence de l’ensemble du système.

Exemple : l’approche anti-processus

L’une des choses les plus importantes que les méthodologies agiles ont réalisées est d’avoir attiré l’attention sur les aspects humains. Le manifeste Agile semble donner plus de valeur a l’humain qu’aux processus et aux outils. Notons que cette affirmation n’est pas exacte car toutes les méthodologies disent que les aspects humains sont importants, et la vraie différence avec les méthodologies Agiles est que les aspects humains sont une partie intégrante de leurs processus, plutôt qu’une simple suggestion. Donc ce n’est pas une compétition entre les aspects humains et les processus, mais un accent particulier sur la façon dont les aspects humains sont traités dans le système.

Il ne fait aucun doute que certaines personnes essaient de remplacer les aspects humains par des processus plus sophistiqués, mais ce n’est qu’une mauvaise pratique. Même le contraire existe également : des personnes essayant de remplacer des processus par des aspects humains, ce qui ne fonctionne pas bien non plus.

Exemple : voici tous les domaines requis

Lorsque vous réfléchissez aux domaines, veillez à ne rien omettre. Mais que sont les domaines ? Si vous vérifiez les bases de connaissance fondamentales, vous obtiendrez des réponses différentes et pourtant, aucune d’elles n’est toute la vérité.

Les thèmes de PRINCE2® sont des domaines, mais ce ne sont que des domaines qui jouent un rôle clé dans la méthodologie. Tous les autres domaines importants n’y sont qu’implicites. Le Guide PMBOK® n’est pas une méthodologie et peut donc traiter le sujet en profondeur avec les dix domaines de connaissances. Cependant, il s’agit d’interprétations (de tous les domaines) fondées sur la perspective du projet par le Guide PMBOK®, et non de manière neutre (ce n’est pas qu’une perspective neutre existe nécessairement). Par exemple, les aspects humains ne retiennent pas beaucoup l’attention dans le Guide PMBOK®.

ICB est une bonne source d’informations sur les domaines. Cependant, il ne s’agit pas de domaines, mais des compétences requises dans le projet. Il n’est pas comparable trait pour trait aux domaines, mais aide beaucoup à les identifier.

Il n’ya pas de liste de domaines dans Les Principes Quasi Universels de Projets (NUPP - Nearly Universal Principles of Projects), principalement parce qu’il s’agit d’un méta-système plutôt que d’un système, et aussi parce que la catégorisation des domaines dépend du type de projet et de son environnement ; Par exemple, un projet de construction de routine peut nécessiter une perspective différente de celle d’un projet de recherche créatif.


Ne rien faire sans un objectif clair

Vous ne devriez rien faire à moins que cela soit motivé par un objectif clair. Imaginez deux mondes parallèles où tout est identique, sauf ce que vous envisagez : jusqu’à quel point seraient-ils différents ? La différence vaut-elle l’effort que vous investirez ?

Si vous n’avez pas d’objectif précis et ne faites que parce que tout le monde le fait ou que tout le monde dit que c’est important, alors :

  • Votre cas n’aura peut-être pas un bénéfice réel, et vous ne pourrez donc rien en retirer, Ou
  • Il peut toujours avoir des bénéfices potentiels dans votre cas, mais comme vous n’avez pas l’objectif en tête, votre façon de le faire ne vous aidera peut-être pas à en tirer des bénéfices.

Exemple : portefeuilles et programmes

Si vous êtes impliqué dans la sélection et le lancement de projets, vous devez vous concentrer sur les bénéfices et les problèmes qui sont censés être résolus avant le produit qui va concrétiser ces choses. L’exemple classique est celui du fabricant d’ascenseurs qui recevait autrefois des plaintes concernant la vitesse de leurs ascenseurs et qui lançait plusieurs projets pour augmenter la vitesse de ses ascenseurs sans succès. Cela a continué jusqu’à ce qu’ils décident de se concentrer sur le problème (ennui ou inconfort des gens) au lieu de la solution « naturelle » (ascenseurs plus rapides). Résultat : ils ont ajouté des miroirs aux ascenseurs, ce qui a tout simplement résolu le problème.

Rappelez-vous que la gestion de projet consiste principalement à bien faire les choses, alors que la gestion de portefeuille consiste à faire les bons choix. Peu importe la qualité de la gestion de vos projets, cela ne fonctionnera pas si vous choisissez les mauvais projets. Il s’agit d’avoir un objectif.

Exemple : le projet dans son ensemble

La flexibilité du produit varie selon les projets. Dans certains projets de développement informatique, le produit est totalement flexible et sa forme finale dépend du retour d’informations généré par les incréments du produit au cours du projet, ce qui nécessite une approche adaptative (Agile). Il s’agit pratiquement d’une combinaison des couches portefeuille, programme et projet, et doit faire l’objet d’une attention maximale à l’ultime objectif. C’est une bonne idée de documenter l’objectif et de le rendre accessible ; c’est l’un des buts visés par la « vision produit » utilisée dans certains types de projets tels que les projets Scrum. L’attention portée à la valeur commerciale dans les projets Agiles est leur moyen d’assurer l’alignement sur leur objectif.

Dans d’autres types de projets, où le produit est relativement fixe et qu’il existe d’autres mécanismes pour garantir que le produit identifié satisfera à l’objectif recherché, il est possible pour les membres de l’équipe de projet de déplacer une grande partie de leur attention du but vers le produit ( d’où le principe de «focus sur les produits» de PRINCE2®), mais un minimum d’attention est nécessaire pour que le produit satisfasse à ce but, ce qui peut être fait en comparant les avantages prévus aux avantages escomptés (d’où le principe de «justification commerciale continue» et le thème «étude de rentabilité» dans PRINCE2®).

Lorsque le projet est à réaliser pour des clients externes, le client a son propre objectif et votre entreprise a un objectif différent. Vous devez comprendre et utiliser les deux pour vraiment réussir.

Exemple : le suivi de projet

Garder l’objectif ultime en vue est nécessaire, mais il peut s’avérer trop abstrait pour la plupart des tâches quotidiennes. C’est pourquoi une hiérarchie d’indicateurs est nécessaire pour le rendre plus pratique. Tout d’abord, la justification et les bénéfices du projet sont définis en fonction de l’objectif ultime, puis vous aurez des objectifs explicites et implicites pour les variables du projet (par exemple, le temps, le coût et la qualité) afin de satisfaire la justification, ce qui à son tour satisfera le l’objectif ultime. Ce sont des objectifs de niveau inférieur qui sont utiles pour beaucoup de nos tâches quotidiennes.

En ce qui concerne le suivi, le contrôle de bas niveau du projet sera effectué en utilisant le plus bas niveau de variables, car il ne sera peut-être pas possible de suivre l’objectif ultime. Dans ce cas, vous devriez toujours avoir les objectifs en tête : quel est l’objectif du suivi ?

Une réponse normale et acceptable consiste à voir si nous sommes sur la bonne voie et, sinon, à déclencher une réaction qui nous ramènera sur la bonne voie ou ajustera les variables pour voir si ces ajustements peuvent toujours nous permettre d’atteindre l’objectif ultime. Par conséquent, nos mesures devraient vous permettre de traiter cet objectif de bas niveau, et les mesures appropriées sont des prévisions pour les variables à la fin ; c’est-à-dire, quand serions-nous en mesure de terminer le projet ? De quel budget aurions-nous besoin pour terminer le projet ? Etc.

Toutes les autres mesures, telles que les valeurs planifiées et réelles à ce jour, ne sont que des valeurs intermédiaires dont vous avez besoin pour calculer les prévisions, et non les valeurs finales que vous utilisez à des fins de gestion.

Exemple : les documents

Quelle que soit l’approche de développement que vous utilisez dans le projet, la planification est toujours nécessaire. La question importante est le niveau de détail de chaque type de plan. Si le plan n’est pas suffisamment détaillé, sa contribution sera négligeable et l’exécution du projet reposera davantage sur des décisions ad hoc que sur des décisions holistiques et intégrées. Par ailleurs, de nombreuses personnes essaient d’être prudentes et d’ajouter trop de détails à au plan, ce qui rend sa préparation et sa maintenance trop difficiles, et trop rigide pour les incertitudes du projet. Par conséquent, le plan devient irréaliste et inutile.

La meilleure façon de décider du niveau de détail du plan est d’avoir un objectif en tête ou de considérer tous les éléments déterminants du plan. Par exemple, si vous envisagez d’ajouter une ressource au plan, vous devez avoir un objectif : comment allez-vous l’utiliser ? Comment cela aiderait-il le projet ? Quel effort sera nécessaire pour l’intégrer, cela en vaut-il la peine ?

Il s’agit parfois de décider si vous souhaitez inclure un élément dans vos plans, et parfois de choisir votre façon de planifier ou de préparer quelque chose. Prenez une étude de rentabilité, une charte de projet ou un rapport : vous devez toujours vous demander pourquoi vous préparez ce document et en quoi il peut aider le projet. La recherche d’un «exemplaire» est le contraire de faire quelque chose basé sur un objectif.

Exemple : le rapport sur l’état du projet

Il est courant d’avoir des rapports d’état très longs dans de nombreux projets. Sur la base de ces Principes Quasi Universels (NUP - Nearly Universal Principles), nous devrions nous demander quel est l’objectif du rapport et comment nous pouvons atteindre cet objectif, indépendamment de ce que la plupart des gens peuvent faire.

Cela peut, dans de nombreux cas, nous amener à préparer des rapports très simples d’une page que les parties prenantes lisent et comprennent vraiment au lieu de longs rapports. C’est aussi cela faire attention à l’objectif.

Cependant, si vous préparez des rapports d’une page, certaines personnes peuvent vous objecter et penser que vous ne disposez pas d’un système de suivi « approprié ». Cela crée pratiquement un second objectif pour vous (outre le premier objectif, qui consiste à aider les parties prenantes à comprendre le statut du projet), et pour le satisfaire, vous pouvez simplement créer un second type de rapport très long. Cependant, vous ne combinerez pas cela avec le premier rapport, car ces deux objectifs ne sont pas les mêmes.

Exemple : les études de rentabilité et la charte de projet

Préparer des documents tels qu’une étude de rentabilité et une charte de projet est généralement une nécessité fastidieuse, infructueuse et bureaucratique pour la plupart des gens, alors que ces documents ont tous des objectifs valables qui s’appliquent à la plupart des projets. Si vous essayez de trouver un “modèle” et remplissez le modèle, le travail est simplement inutile, alors que vous pouvez plutôt vérifier le but réel de ces documents, voir comment et s’ils peuvent être utiles dans votre projet, puis préparer le document comme vous le souhaitez, rien que pour satisfaire ces objectifs : c’est le bon document.

Pendant que vous réfléchissez à la manière dont vous pouvez préparer les documents pour répondre à leurs objectifs, vous pouvez ne pas penser à tous les scénarios et rater quelque chose. Pour éviter cela, vous pouvez vérifier ce que suggèrent PRINCE2®, Guide PMBOK®, et DSDM®, puis évaluer ces suggestions en fonction des objectifs visés.

Exemple : le suivi post-projet

Bien que le projet ait un objectif précis et que nous puissions en tenir compte tout au long du projet, sa réalisation est principalement évaluée sur la base de prévisions établies au cours du projet, et nous ne devons pas l’oublier une fois le projet terminé. Il est important de vérifier la réalisation des objectifs une fois le projet terminé, car :

  • nous pouvons voir comment les objectifs ultimes sont atteints et en tirer des enseignements pour les projets futurs, et

  • Parfois, les objectifs ne sont atteints que si nous réalisons quelques tâches supplémentaires après l’achèvement du projet, et comprendre la nécessité de ces tâches supplémentaires requiert un suivi.

Le suivi post-projet est une étape nécessaire si vous êtes axé sur les objectifs. C’est principalement la responsabilité des systèmes de gestion de programme et de portefeuille, et comme la plupart des entreprises n’ont pas de tels niveaux de gestion, cette étape est généralement négligée. C’est pourquoi et DSDM® ajoutent cette étape à leurs méthodologies de gestion de projet.

Exemple : la simplicité

Le monde est complexe et chaotique, mais nos modèles sont des approximations abstraites reflétant partiellement le monde. Par conséquent, ils peuvent être simples. D’un autre côté, les systèmes simples fonctionnent généralement mieux, car nous pouvons nous concentrer sur l’usage principale.

Nombre d’entre nous essaient d’obtenir de bons résultats en rajoutant de la complexité à nos systèmes, espérant que cela corresponde à la complexité du monde, même si cela rend le système difficile à utiliser et nous empêche généralement d’atteindre l’objectif recherché.

Exemple : L’adaptation

Les projets ne sont pas les mêmes. Un logiciel de diffusion de musique en ligne impose des conditions très différentes de celles qui seront utilisées pour l’équipement d’un hôpital ou pour un avion dont la vie peut dépendre, ou d’un logiciel qui sera utilisé dans un satellite où il est supposé fonctionner pendant de nombreuses années sans se planter, et ces logiciels sont tous différents de la construction d’une maison de vacances, d’une centrale anti-incendie et d’une usine de traitement.

Une fois que vous avez les objectifs en tête, vous comprendrez mieux comment adapter les systèmes et la documentation à différents projets.


Utiliser des éléments reproductibles

Une approche improvisée du projet épuise en termes d’énergie, de ressources et risque toujours de passer à côté d’éléments nécessaires. La meilleure façon de simplifier ce qui doit être fait est d’utiliser des éléments reproductibles, et de préférence les prendre en cycles reproductibles.

Exemple : les listes de contrôle de la qualité

Une liste est un exemple simple d’un élément potentiellement reproductible que de nombreuses personnes utilisent dans leur vie personnelle et professionnelle. Prenez par exemple les critères de qualité d’un livrable :

  • Tout d’abord, vous pouvez créer une liste de tous les critères, qui est une forme de planification.
  • Le sixième Principe Quasi Universel (NUP6 - Nearly Universal Principle number 6) recommande de standardiser la liste : existe-t-il des livrables similaires dans le projet ? Dans ce cas, préparez une liste générique de contrôle la qualité pour cette catégorie de livrables et utilisez-la pour chacun d’eux. S’il existe des variantes, conservez cette liste et ajoutez-y quelques éléments supplémentaires pour les livrables individuels. Maintenant, vous avez des listes de contrôle reproductibles.
  • Lorsque vous préparez des listes de contrôle génériques pour divers types de livrables, vous pouvez trouver des éléments qui se répètent, ce qui suggère la possibilité de créer une catégorie mère virtuelle pour eux. Dans ce cas, au lieu de répéter les éléments de toutes ces listes génériques, extrayez-les et mettez-les dans une liste mère. Enfin, vous aurez probablement une seule liste générique pour l’ensemble du projet. Les critères d’acceptation de Scrum (Scrum’s Definition of Done) sont un exemple de liste de contrôle de la qualité (entre autres) au niveau du projet. Ce faisant, chaque livrable appartiendra à une hiérarchie de catégories et devra satisfaire les éléments qui apparaissent dans les listes de toutes les catégories de leur chaîne.

Ainsi, un élément de la liste mère devient reproductible pour toutes ses sous-tâches, ce qui permet de gagner du temps et de l’énergie dans la planification et l’exécution. Plus encore, une fois que vous l’avez exploitée pour un projet, vous pouvez l’adapter et l’utiliser pour tous les projets similaires à l’avenir, ce qui constitue une forme reproductible de planification pour plusieurs projets.

Exemple : les processus et flux de travail

Certains livrables ou objectifs qu’ils contiennent nécessitent certaines étapes qui peuvent devenir normalisées et reproductibles. Par exemple, si les produits livrables doivent être conçus individuellement et approuvés, vous pouvez préparer un flux de travail simple qui clarifie toutes les étapes, les personnes impliquées et les durées approximatives, tout en évitant de nombreuses difficultés. Veillez toutefois à ne pas rendre les processus et les processus trop compliqués ou trop exigeants en documentation, car cela aurait des conséquences négatives. Toutes les personnes impliquées dans le projet doivent trouver les flux de travail et les processus comme un support pour leur travail et leur simplifier la tâche, et non comme une documentation bureaucratique qui bloque leur vrai travail.

Les projets agiles ont pratiquement des éléments reproductibles dans leur approche de développement itérative, où certains types d’activités de développement sont répétés pour chaque fonction ; par exemple. la routine quotidienne commune sous XP (eXtreme Programming) : associer, choisir un élément, le concevoir sur un tableau blanc, construire les scripts de test et le code, intégrer le code, etc. Outre les flux de travail reproductibles pouvant être utilisés pour des activités techniques, peut également avoir des éléments reproductibles pour les activités de gestion de projet. Les processus décrits dans les guides PMBOK®, PRINCE2® et DSDM®, les activités dans et les événements dans Scrum sont des exemples de ce concept.

Exemple : les cycles

Avoir des éléments reproductibles pour gérer le projet est utile. Cela peut être rendu encore plus facile en les mettant dans des cycles reproductibles. Ces cycles simplifient considérablement les activités quotidiennes des personnes impliquées dans la gestion et la direction du projet. Les cycles de groupes de processus dans PMBOK® Guide utilisés dans un projet comportant plusieurs phases, des étapes dans PRINCE2®, des cycles quotidiens, hebdomadaires et mensuels dans, des itérations et des boîtes de temps dans DSDM® et des sprints dans Scrum sont des exemples de ce concept.

Les cycles plus courts sont plus faciles à comprendre et à utiliser que les plus longs ; Par exemple, Sprints dans Scrum contrairement aux phases selon le Guide PMBOK®. Toutefois, les cycles trop courts peuvent ne pas suffire pour prendre en charge certains types de projet. La solution peut être l’utilisation de plusieurs cycles, tels que l’utilisation par DSDM® de cycles courts de type timebox avec des cycles d’itération plus longs, ou l’utilisation de par cycles quotidiens, hebdomadaires et mensuels.

Exemple : les méthodologies

L’usage d’une méthodologie ou d’un cadre pour l’exécution d’un projet est un autre exemple d’exploitation d’éléments reproductibles. Il peut s’agir d’une methodologie existante tel que PRINCE2®,, DSDM® ou Scrum, ou d’un système que vous avez personnalisé ou construit vous-même. Cependant, il est généralement préférable de commencer par l’une des méthodologies existantes et de l’adapter à vos besoins plutôt que d’en construire une nouvelle.

Tout élément reproductible est abstrait et doit être personnalisé pour s’adapter à la réalité du terrain. Il existe cependant un éventail d’abstraction et de besoins de personnalisation : des listes de contrôle de qualité courtes et relativement précises se situent à une extrémité de l’éventail avec le minimum d’abstractions et de besoins d’adaptation, tandis que les méthodologies sont à l’autre bout, avec le besoin le plus élevé d’adaptation. Vous devez toujours noter le besoin d’adaptation, sinon l’élément reproductible ne correspondra pas à vos besoins.


NUPP es una colección de principios casi universales para Gestión de Proyectos: Aquellos que seguramente seguiremos en todos los proyectos que gestionemos, indistintamente de las metodologías o enfoques que utilicemos, para asegurar su éxito.

Cada recurso y/o método para gestionar proyectos está directamente relacionado con alguno de estos NUPs (Nearly Universal Principles - Principios casi-universales). Sin embargo, hay que tener en cuenta que:

  • No siempre la totalidad de los NUPs son tenidos en cuenta dentro de una mismo método-recurso. No obstante, sería de gran utilidad que los practicantes los consideren en su totalidad y no de forma separada. Además,
  • Los principios generalmente no están desarrollados de forma clara en la documentación relativa al recurso y la mayoría de los practicantes, al estar tan envueltos en detalles prácticos, generalmente suelen pasarlos por alto y lamentablemente, toman decisiones que no son compatibles con estos principios.

NUPP es compatible con la mayoría de los métodos, sistemas, recursos y marcos tales como PRINCE2®, Guía Del PMBOK®,, PM², DSDM®, XP y Scrum. La diferencia la encontramos en la interpretación que se le da a estos sistemas. Y es aquí cuando NUPP intenta fomentar en los practicantes a reconsiderarlas. Los principios NUP son:


Preferimos resultados y transparencia a filiación

Todos tenemos una tendencia natural a sentirnos identificados o pertenecer a un grupo, que generalmente trasciende su forma básica, crea vínculos fuertes, y también puede traer inconvenientes. Generalmente, perdemos más de lo que ganamos a causa de las filiaciones. Podemos convertirnos en mejores profesionales y expertos más efectivos si no limitamos nuestra identidad y/o preferencias a ciertos grupos.

Ejemplo: Metodologías Agiles vs Waterfall

Un grupo de gente muy entusiasta que fue lo suficientemente valiente para tratar de implementar un marco de desarrollo de software adaptativo cuando la regla general establecía marcos predictivos unió sus fuerzas y lo llamaron Ágil. Ésta fue una gran iniciativa para no limitar las opciones de lo que ya parecía necesario e inmutable. Hoy en día, dentro de la comunidad ágil nos encontramos con muchos entusiastas y personas basadas estrictamente en resultados. Desgraciadamente, hay algunas personas en esta comunidad que convirtieron la metodología ágil en un culto y consideran a todos aquellos que no la practican enemigos. Esto causa problemas de diversa índole, incluyendo:

  • La imposibilidad de aprender de alguien-algo fuera de su grupo.
  • La negativa de personas ajenas a su entorno de aprender de ellos.
  • La sensación de que es más importante pertenecer al grupo que el propósito real, que en práctica impide a muchos miembros aprender el significado real de la metodología.

Éstos inconvenientes pueden ser fácilmente mitigados, si no eliminados, utilizando “ÁGIL” como una etiqueta que solo se refiere a un tipo de desarrollo más que a una comunidad con miembros, que incluye personas que se consideran ´creadores´, ´solucionadores de problemas´ y ´líderes´, que usan ágil como un medio para un fin y no como su identidad.

Para un profesional de verdad, no existe la guerra Ágil-Waterfall.

Ejemplo: PRINCE2® vs Guía Del PMBOK®

Hay muchos profesionales en esta comunidad que se identifican exclusivamente con PRINCE2® o Guía Del PMBOK® (generalmente debido a su ubicación geográfica) y no están familiarizados en absoluto con otros recursos. Todos podemos tener una tendencia hacia ciertos recursos específicos, pero no deberíamos convertirlos en nuestra identidad. Lo que es más trascendental todavía, es que deberíamos familiarizarnos con la mayor cantidad de recursos posibles para ampliar nuestra perspectiva y nuestras elecciones.

Un profesional de verdad está abierto a todas las ideas, busca, aprende y las utiliza cuando sean necesarias, sin ningún tipo de filiaciones.

Ejemplo: Aprendizaje continuo

Las filiaciones suelen llevar a los individuos a una zona de confort y no los impulsa a aprender, muchas veces hasta incluso los desmotiva totalmente a adquirir nuevos conocimientos por miedo a perderlos. Cuando eres una persona libre, un experto sin filiación alguna, necesitas cubrir esto aprendiendo, pero aprendiendo de forma continua.

Lo que hoy creemos, no es la verdad absoluta, sino nuestro mejor entendimiento de acuerdo a lo que hemos aprendido. Esto evolucionará a medida que vayamos adquiriendo mayor conocimiento. Algo no funciona del todo bien si tenemos las mismas ideas que teníamos hace unos años atrás. Este es el caso exacto de NUPP: Si volvemos atrás unos años y vemos exactamente lo mismo, debemos empezar a sospechar.

Ejemplo: Honestidad

Cuando no estamos de acuerdo con alguien, asegurémonos de que nuestro objetivo sea la idea, no la persona. Esto ayuda a prevenir numerosos enfrentamientos y tensiones innecesarias. De la misma forma, cuando alguien no está de acuerdo contigo, intenta no tomarlo personal, sino como una discusión sobre tu idea, procurando mantenerte siempre abierto a ella. No escuches para responder, escucha para entender y trabaja con la otra persona para mejorar la idea inicial.

A veces, algunas personas pueden intencionalmente tenerte a ti como objetivo en vez de tu idea. En este caso, ayúdales a enfocarse en la idea en vez de en tu persona e intenta mantener la misma línea durante toda la conversación.


Preservamos y optimizamos la energía y los recursos

En general, los recursos son limitados. Y nuestro proyecto no suele ser la excepción, como tampoco lo es la energía mental que necesitas para tomar buenas decisiones. Debes preservar y optimizar estos recursos para ti, y para tu proyecto, así como ayudar a otros miembros del equipo a hacer lo mismo.

Ejemplo: La regla 80/20

Una gran parte de los posibles beneficios de la gestión de proyectos es generalmente posible solo con una porción muy pequeña de esfuerzo. En mucho de los casos, tener como objetivo el 100% de los posibles beneficios es muy costoso e injustificado.

Tener en cuenta esta regla en todo lo que haces y fomentar esta misma practica en otros es vital.

Ejemplo: Fatiga de decisión

Utilizamos una sola fuente de energía mental para tomar todo tipo de decisiones y exteriorizar nuestros deseos. Si utilizamos injustificada e indiscriminadamente esta fuente, tendrás menos energías para aquellas decisiones que sí lo son, y puede redundar en malos resultados. Esta es una de las razones por las cuales debes evitar el micro-management (y seguir el principio “Gestión por excepción” de PRINCE2®.)

Aquellos conflictos que tienen como epicentro ideas, pueden ser útiles. En cambio, aquellos que tienen como epicentro personas generalmente dañan los proyectos. Una de sus consecuencias es que drena la energía mental de los miembros del equipo. Si te ves envuelto en un conflicto similar, debes hacer lo posible por encontrar la raíz del problema y solucionarlo.

Ejemplo: Cuida de ti mismo!

Las decisiones que tomas y lo que expresas desgastan tu energía mental. Por otra parte, esta fuente de energía se “regenera” cuando duermes y comes adecuadamente. Así que, cuida de ti mismo: Asegúrate de que duermes y descansas lo suficiente, y come de forma adecuada. Si tienes hábitos dañinos o problemas para conciliar el sueño, no tienes que lidiar con ello a nivel personalísimo, hay muchos especialistas que pueden ayudarte a solucionar eso de forma fácil. La actividad física también puede ayudar a regenerar esa fuente de energía, aunque no hay estudios concluyentes por el momento.

Intenta fomentar esta visión a los miembros de tu equipo. Primero, asegúrate de que estas trabajando de forma continua y sin demasiadas horas extra. Después, si puedes, intenta ofrecer snacks energizantes, comida sana y bebidas durante el horario laboral.

Ejemplo: Balance entre trabajo y vida privada

Muchos de nosotros amamos nuestra profesión, pero sin embargo, esto no lo es todo lo que necesitamos en nuestra vida. De la misma forma que optimizas tu trabajo, debes planear e implementar ideas en tu vida privada, de forma que la disfrutes y seas feliz. Cuando lo eres, también serás más exitoso en el trabajo. Si puedes, fomenta esta visión en tus compañeros de equipo.

Ejemplo: Motivación

La motivación es un concepto complejo. Hay muchos recursos interesantes y útiles sobre el tema, pero sin embargo, muchos que no tienen base científica. De todas formas, debes aprender de ellos y utilizarlos de forma continua, ya que aumenta la energía mental del equipo y la posibilidad de tener mejores resultados en el proyecto. Un buen ejemplo de motivación puede ser dar a entender a los miembros de tu equipo que reconoces su buen trabajo, siendo amables con ellos o incluso agradeciéndoles directamente. Sin embargo, debemos tener cuidado con algunos métodos tradicionales de motivación, ya que pueden tener efectos negativos, como por ejemplo, un bonus salarial pequeño.

Ejemplo: Colaboración y trabajo en equipo

Las personas que cooperan con otras generalmente tienen el poder de crear mejores resultados, pero lo que es más importante, es destacar que el ser humano es social por naturaleza y disfruta siendo parte de un grupo.

Si puedes, deshazte de aquellos aspectos negativos del trabajo en grupo y crea un ambiente amigable y distendido. Esto hará que los miembros de tu equipo sean más felices.

Sin embargo, cuidado, ya que todos somos diferentes, y podemos encontrarnos con miembros que disfruten más de un ambiente relajado y solitario que otros – lo importante es encontrar un balance.

Ejemplo: Cultura de “Somos un solo equipo”

Suele haber una tendencia por parte de algunas personas de crear o considerar subgrupos y crear tensión con otros pares. Por ejemplo, las personas que están enfocadas en los aspectos de negocio del proyecto vs. Las personas que están construyendo el producto.

La tensión consume muchísima energía de ambas partes, y es una de las razones principales por las cuales tendríamos que intentar construir la cultura de un solo equipo, cuando todos trabajan juntos para lograr un mismo objetivo.

Ejemplo: La sabiduría de las masas

Cuando un grupo grande y diverso de personas se juntan y trabajan juntos en un ambiente colaborativo, hay potencial para muy buenos resultados, ideas y soluciones, que pueden ser incluso mejores que aquellos que vienen de un solo experto.

Si tienes ésta opción, puedes utilizarla de forma regular y preguntar a los miembros de tu equipo si pueden ayudarte a solucionar problemas difíciles en el proyecto. Además de la posibilidad de tener buenos resultados, también permite a los miembros del equipo sentirse útiles y que su rol también es importante en el proyecto, lo que resulta en mayor nivel de energía. La actividad #26 de es un ejemplo claro de cómo se utiliza la sabiduría de masas en proyectos.

Ejemplo: Líder de proyecto estilo facilitador

Si eres un Project Manager, el epicentro de tu actividad se basa en facilitar (o al menos, así debería ser). Por otra parte, puede ser que miembros de tu equipo tengan malas experiencias con Project Managers en su pasado, e incluso que esas experiencias impacten en su relación contigo: una porción de su energía es destinada directamente a analizar tu comportamiento e intentar detectar posibles “amenazas” en vez de confiar en ti.

En este caso, puedes cambiar tu título, y en vez de llamarte Project Manager puedes llamarte Chief Project Facilitator.


Proactividad ante todo

Los humanos tenemos una tendencia natural a ser reactivos. Nos ayuda a preservar nuestra energía en caso de asuntos que no son importantes y nos da mejores resultados cuando estamos lidiando con algo en lo que somos totalmente inexpertos. Aquellas situaciones son totalmente diferentes de nuestros proyectos, y aquí es donde podemos tener mejores resultados siendo proactivos.

Ejemplo: Hacer planes

Si tienes como destino un sitio desconocido y ya estáis llegando tarde, puedes empezar a conducir inmediatamente para “ahorrar tiempo”, y solucionar los problemas cuando aparezcan. El punto de vista proactivo es tomarse algo de tiempo y programar el GPS o sistema de navegación para que te provea la ruta más rápida basada en el tráfico, posibles accidentes, rutas en servicio y luego conducir. Esto se basa en reservar un tiempo antes de ejecutar para evitar problemas de forma anticipada y ahorrar tiempo de verdad.

Al contrario de lo que algunas personas piensan sobre los proyectos ágiles, planear es siempre necesario, y va más allá del tipo y nivel de detalles. Hacer planes antes de ejecutar es un enfoque 100% proactivo.

Siempre tengamos en mente la frase: “Dame seis horas para cortar un árbol y pasaré las primeras cuatro afilando el hacha.”

Si en cambio, tenemos un proyecto predictivo, puedes tranquilamente pasar cuatro horas afilando el hacha, porque estás seguro que lo que quieres hacer es cortar un árbol. En un proyecto ágil, no estáis seguros de si queréis cortar un árbol, pillar ramas rotas, cortar el césped, extraer carbón u otra cosa.

Sin embargo, necesitas estar medianamente preparado para todas las posibilidades (como saber dónde está la tienda más cercana donde se puedan comprar herramientas), y tener una preparación específica (en este caso, saber afilar) cuando vais a focalizaros en una solución especifica. Eso es hacer planes.

Ejemplo: Planear los planes

Planear la forma en la cual vais a ejecutar el proyecto es un enfoque proactivo. Ésta proactividad puede ser extendida incluso hasta el extremo de planear la forma en la cual vais a planear la ejecución.

Este concepto está relacionado con la Gestión de Planes en PMBOK® Guide, estrategias de gestión en PRINCE2® y enfoque en DSDM®.

Ejemplo: Planear de forma continua

La realidad no suele coincidir con lo que planeamos, y no hay ningún problema en ello.

Sin embargo, necesitamos adaptar de forma continua nuestros planes para asegurarnos de que son realistas y prácticos. Necesitamos hacerlo en cuanto veamos la necesidad de adaptar, no cuando los problemas ya están presentes. Esto es un enfoque proactivo.

Ejemplo: Gestión de riesgos

El concepto global de gestión de riesgos está basado en la proactividad: Cuando eventos desconocidos aparecen, en vez de esperar a ver qué sucede y luego reaccionar ante ellos, pensamos previamente en posibilidades, impacto, posibles respuestas y probablemente intentamos tomar medidas antes de que suceda.

Por favor, tomar en consideración que muchas veces, hay vidas de personas envueltas en los objetivos de nuestros proyectos.

Ejemplo: Definir roles y responsabilidades

Puedes dejar que los miembros de tu equipo trabajen sin roles ni responsabilidades definidas y, tarde o temprano de forma implícita surgirán, pero es muy costoso y puede que al final de cuentas, no de buen resultado. El enfoque proactivo es definirlos de antemano y adaptarlos según sea necesario. Esto redunda en facilitar el trabajo para todos, y focalizar los esfuerzos en producir algo, más que en decidir quién hace qué.

El número y la variedad de roles pueden depender de acuerdo al tipo y tamaño del proyecto. Puede ser una simple definición – como en Scrum -, algo moderado – como en – o bien algo más amplio -como en DSDM® o PRINCE2®-. De todas formas, no nos olvidemos de que las descripciones de roles en los métodos mencionados se refieren solamente a actividades de gestión, y siempre es necesario añadir también descripciones de roles para aspectos técnicos.

Ejemplo: Opciones disponibles

¿Debo terminar el proyecto de forma prematura o continuar con él?

Muy pocas veces hay solamente dos opciones, incluso si la pregunta nos lo sugiere implícitamente. Necesitas utilizar un enfoque proactivo y considerar todas las opciones antes de tomar una decisión. Tal vez puedes redefinir el alcance del proyecto, tal vez puedes suspenderlo hasta que se aclare el panorama, tal vez puedes cambiar el enfoque del proyecto (ej. Externalizarlo), etc.

Ejemplo: Pensamiento crítico

Todos tenemos ciertas predisposiciones (también llamados sesgos) que pueden ayudarnos a sobrevivir por un lado, y por el otro llevarnos a tomar malas decisiones. Cuando hay que tomar decisiones importantes en un proyecto, es mejor tomarnos un momento y considerar nuestras predisposiciones o prejuicios y de que forma puedan llegar a afectar nuestra decisión antes de que se conviertan en un problema.

Como una referencia, puedes utilizar la siguiente lista de sesgos cognitivos en Wikipedia:

También existen ciertos marcos para tomar decisiones que puedes utilizar como referencia. Primero, puede alejarte de tu idea inicial e incluso llegar a molestarte, pero pronto te acostumbrarás a ellos y sacaras ventaja casi de forma inconsciente.

Ejemplo: Transparencia

A nadie le gusta tener problemas o demorarse en un proyecto, pero esto no significa que debamos esconderlo. Seamos transparentes y comuniquémoslo a nuestros pares, algunos de ellos incluso pueden ayudarnos. Tarde o temprano, van a saberlo.

Además, al saberlo por anticipado, en caso de que necesiten realizar algunas acciones, les daremos tiempo para elaborarlo y ejecutar las acciones que crean convenientes. (Ejemplo: Aceptar las consecuencias negativas)

Ejemplo: Comuniquémonos de forma efectiva

Habrá muchos casos en los que enviemos reportes a las personas involucradas en el proyecto, sin recibir una respuesta concreta de su parte. Puedes creer que esto no es ningún inconveniente ya que no hay ningún comentario negativo, pero puede ser que sí lo sea.

Tienes que ser proactivo y asegurarte de que han utilizado el reporte de forma adecuada y han sido provistos de los datos necesarios, y utilizar esto para ajustar tu método de comunicación.

De otra forma, se pueden crear problemas de diferente índole, que serán difíciles de solucionar.

Ejemplo: Se responsable

Es muy fácil culpar a los demás de los malos resultados. Por ejemplo, tu deseas que en tu organización se te dé autoridad total de ejecutar cambios dentro del marco del proyecto y así, concretar los objetivos de forma perfecta. No lo hacen, y por lo tanto, el proyecto falla. Esto no es un enfoque proactivo.

El enfoque proactivo es asumir la responsabilidad y hacer todo lo que puedas a pesar de las dificultades. No puedes esperar que en tu organización todos crean ciegamente en ti y te den todos los recursos esperando tener buenos resultados a cambio, especialmente cuando ya han visto proyectos fallidos previamente. Lo que tienes que hacer es ejecutar una simple mejora a pesar de las dificultades que se presentan, utilizar eso para ganar su confianza, solicitar un poco más de recursos y un poco más de margen de tolerancia para dificultades y utilizar esto para ejecutar una mejora un poco más grande y seguir de ésta forma hasta que llegues al objetivo óptimo.


Recordamos que la cadena es tan fuerte como su eslabón más débil

En cada proyecto hay distintos dominios, y todos ellos requieren atención. Debemos tener una perspectiva holística del proyecto. Prestar atención a los dominios de obvia importancia, como por ejemplo el tiempo, no es suficiente, ya que todos los dominios interactúan entre si y no suelen funcionar de forma correcta a menos que todos ellos reciban la dedicación adecuada.

Ejemplo: Todo se resume a la fecha límite

Imagina que estas construyendo algo para los Juegos Olímpicos. La fecha límite es un elemento crucial, lo que automáticamente convierte a la gestión del tiempo también en un elemento clave para gestionar, ¿Cierto?

¿Qué pasaría si, por ejemplo, la calidad fuese tan baja que, pasado el tiempo, requiere rehacer el trabajo ya hecho, teniendo un impacto directo en el tiempo? Entonces ya, no solo hablamos de tiempo, sino también de calidad.

Tal vez, en la definición original del proyecto tengas un jardín muy bonito, pero, como sabes que no dispones de tiempo suficiente, puedes pasarlo por alto y cubrir el área solamente con césped, en tanto y en cuanto hayas considerado esta posibilidad en tiempo y forma y lo hayas previsto. Por lo tanto, manejar el alcance también es importante, lo que ahora hace que tengamos tiempo, calidad y alcance como epicentro de nuestro proyecto.

¿Habéis escuchado este famoso ejemplo cuando el presidente Kennedy se entrevista con un conserje de la NASA y le pregunta a que se dedica, y el responde: “Ayudo a mandar hombres a la Luna!”? ¿Acaso no ayuda a cumplir con las fechas límite personas en tu proyecto que repliquen la actitud de éste conserje?

A medida que avanzas, notarás que cada dominio dentro del proyecto está relacionado con la gestión del tiempo, y por lo tanto, será difícil cumplir con la fecha límite con una certeza aceptable a menos que prestes atención a todos los dominios.

Ejemplo: Selección a consciencia (o también llamado “Cherry picking”)

Cuando las personas están en contacto con varias metodologías, en algún momento pueden comenzar a seleccionar de forma intencional aquellos conceptos/recursos/ideas que le son interesantes de distintos sistemas y mezclarlos entre sí. Generalmente, esto no suele dar buen resultado, ya que los elementos no funcionan de forma aislada y necesitan ser compatibles entre sí. Cualquier cambio o modificación a un sistema, debe hacerse siempre desde un punto de vista holístico.

Esta es la razón por la cual muchas veces vemos elementos contradictorios en diferentes metodologías. A veces, vemos cosas que funcionan bien en un sistema, y a su completo opuesto funcionando también de forma correcta en otro sistema. El elemento en sí mismo, no es ni correcto ni incorrecto. Todo depende del contexto en el que sea aplicado.

El enfoque más seguro para seleccionar una metodología bajo la cual conducir nuestro proyecto, personalizarlo y luego, de forma concienzuda añadir nuevos elementos es siempre considerando la consistencia global del sistema.

Ejemplo: El Enfoque anti-proceso

Una de las mejores cosas que tienen las metodologías agiles es que centran la atención en el factor humano. El Manifesto ágil añade muchísimo más valor al factor humano que a los procesos y herramientas, aunque esto no sea una comparación del todo justa. Todas las metodologías coinciden en que el factor humano es muy importante, pero el factor diferenciador de las metodologías agiles es que los factores humanos están directamente incorporados en los procesos, más que simplemente proveer sugerencias. Esto no lo convierte en una competición entre factores humanos y procesos, sino en cómo los factores humanos son apreciados en el sistema.

No hay duda que algunas personas intentan reemplazar la falta de factor humano con una sofisticación de sus procesos, pero esto solamente es un uso indebido. También existe el opuesto a la situación mencionada anteriormente: Personas intentando reemplazar procesos con factores humanos, lo que tampoco suele funcionar bien.

Ejemplo: Estos son todos los dominios que necesitas

Cuando pensamos en los dominios de nuestro proyecto, debemos tener cuidado de no dejar ninguno de lado. Pero, ¿Qué son los dominios? Si consultas las diferentes fuentes de información disponibles, recibirás diferentes respuestas y aun así, ninguna de representa la verdad absoluta.

PRINCE2® utiliza las Temáticas como Dominios, pero éstos son solamente los dominios que juegan un papel clave en la metodología. Los otros dominios están presentes de forma implícita.

La Guía Del PMBOK® no es una metodología, y puede formularlo de forma más adecuada con 10 áreas de conocimiento. Sin embargo, éstas son interpretaciones de todos los dominios basados en la perspectiva de la Guía Del PMBOK® para gestionar el proyecto, que no es una visión neutra (aunque esto no signifique que efectivamente deba serla). Por ejemplo, los factores humanos no juegan un papel clave ni reciben mucha atención en la Guía Del PMBOK®.

Una buena fuente de información sobre los dominios es ICB. De cualquier forma, no es solamente sobre los dominios en sí, sino de las competencias requeridas para el proyecto. No incluye una relación 1:1 con los dominios pero ayuda muchísimo a su correcta identificación.

En NUPP no hay una lista de dominios, principalmente porque es un meta-sistema, no un sistema en sí y también debido a que la categorización de los dominios depende en el tipo de proyecto y su ecosistema. Por ejemplo, una construcción puede requerir una perspectiva distinta que un proyecto de I+D creativo.


No realizamos tareas en tanto y en cuanto no tengamos un propósito claro

No debes realizar ninguna tarea sin antes tener una razón válida por la cual efectuarla. Imagina dos mundos paralelos donde todo es igual, salvo una sola cosa, que es la que tú estás considerando actualmente: ¿Cuán diferentes podrían ser estos mundos? ¿Vale la pena dedicar tu esfuerzo a realizar esta tarea?

Si no cuentas con un propósito claro en mente y solo lo haces porque todos lo están haciendo o todos dicen que es importante que este hecho, entonces:

  • Puede ser que no tenga un beneficio claro en tu caso, y por lo tanto no saques ningún beneficio de ello, o que
  • A pesar de tener potenciales beneficios en tu caso, pero debido a que no tienes el propósito claro, la forma en la que lo realices no ayude a materializar estos potenciales beneficios.

Ejemplo: Portfolios y programas

Si estás involucrado en seleccionar e iniciar proyectos, debes asegurarte de que tu atención esté centrada en los beneficios y en solucionar aquellos potenciales incidentes que puedan surgir a causa de desarrollar el producto. El ejemplo clásico es una compañía que fabrica ascensores que solía recibir quejas sobre la velocidad de sus ascensores y había intentado conducir, sin éxito, varios proyectos para aumentar la velocidad de sus ascensores.

Esta situación fue una constante hasta que decidieron centrarse en el problema (el aburrimiento de la gente o la incomodidad) en vez de la solución “natural” (ascensores más rápidos).

El resultado fue, añadirle espejos a los ascensores, lo que resolvió de forma simple el problema.

Recuerda que gestionar proyectos es básicamente hacer las cosas bien, mientras que gestionar portfolios es hacer las cosas correctas. No importa que tan bueno seas gestionando proyectos, no funcionara si estas realizando los proyectos equivocados. Tener un propósito lo es todo.

Ejemplo: El proyecto como un conjunto

La flexibilidad del producto varia de proyecto en proyecto. En algunos proyectos de desarrollo de aplicaciones de IT, el producto es completamente flexible, y su forma final depende de la respuesta que se vaya generando a los incrementos entregados del producto durante el proyecto, que requiere un enfoque adaptativo (Ágil). Esto es, en la práctica, es una combinación de las distintas capas de gestión - portfolio, programa y proyecto- y requiere que prestemos máxima atención al propósito global. Es una buena idea documentar el propósito y tenerlo siempre accesible. Es uno de los propósitos de la “Visión de producto” utilizado en alguno de los proyectos, como por ejemplo en Scrum. La atención al valor de negocio que nuestros incrementos brindan es la forma de asegurar, en este caso en los proyectos bajo la metodología ágil, la correcta alineación del proyecto con el propósito.

En otro tipo de proyectos, cuando el alcance del producto esta medianamente definido y existen otros mecanismos para asegurarse de que el producto identificado valdrá para el propósito establecido, es posible para los miembros del equipo desviar una gran parte de la atención del propósito al producto (Como el principio de “Enfoque en los productos” de PRINCE2®). Sin embargo, siempre debe dedicarse un mínimo de atención a propósito a fin de asegurarse de que el resultado del producto que se está construyendo pueda satisfacer el propósito, pudiéndose comprobar con simplemente comparar el pronóstico de los beneficios con los beneficios esperados (Como el principio “Justificación comercial continua” y la temática “Business Case”, ambos en PRINCE2®.)

Cuando el proyecto es realizado para clientes externos, el cliente tendrá su propio propósito por el cual realizar el proyecto, distinto generalmente del de tu organización. Debes entender y tener en cuenta ambos para tener éxito.

Ejemplo: Controlar el proyecto

Utilizar el propósito global es necesario, pero puede ser demasiado abstracto para su aplicación en las tareas diarias. Por lo cual, establecer una jerarquía efectiva de razones es necesario para poder tener un enfoque práctico. En primer lugar, la justificación y beneficios del proyecto son definidos de acuerdo al propósito global. Como resultado, tendrás objetivos implícitos y explícitos aplicables a las diferentes variables (tiempo, coste, calidad, etc.) que satisfarán la justificación y que, resultará a su vez en lograr el propósito global. Estos son propósitos de bajo nivel que son útiles para mucha de nuestras tareas diarias.

Cuando se trata de controlar el proyecto, gestionar los propósitos de bajo nivel será llevado a cabo utilizando las variables que también conforman el espectro de bajo nivel, ya que no sería posible de otra forma controlar el propósito global. En este caso, también debes tener en cuenta los propósitos. ¿Cuál es el real significado de llevar a cabo tareas de control sobre un proyecto?

Una respuesta válida seria para ver si nuestro proyecto está en la línea correcta y sino, poner en marcha ciertas acciones que nos hagan volver a nuestro cauce o bien ajustar los objetivos y asegurarnos de que todavía podemos seguir cumpliendo con el propósito global. Por lo tanto, nuestros indicadores deberían complementar estos propósitos de bajo nivel, siendo sus indicadores – cuando están definidos y aplicados de forma correcta – pronósticos para las variables una vez completas. Ejemplo: ¿Cuándo podré terminar este proyecto? ¿Cuánto dinero necesitaría para terminar este proyecto?

Todos aquellos indicadores adicionales, tales como los valores planeados y actuales, solo conforman un grupo de valores que necesitas para realizar pronósticos, no formando parte de aquellos que utilizas para gestionar el proyecto en sí.

Ejemplo: Documentos

Sin importar que enfoque de desarrollo utilices en tu proyecto, planear siempre es una parte necesaria. La cuestión importante es definir el nivel de detalle en cada tipo de plan. Si el plan no está lo suficientemente detallado, el plan en sí mismo no podrá contribuir de forma sustancial al proyecto y su ejecución radicara más en decisiones tomadas en una situación particular en vez de decisiones que forman parte de un enfoque integrado y, por lo tanto, holístico.

Por otra parte, mucha gente es reticente a la hora detallar más de la cuenta sus planes, ya que, de esta forma, el plan se convierte en un elemento difícil de preparar, mantener y puede ser demasiado rígido para las incertidumbres que el proyecto pueda presentar, convirtiéndose en un elemento irrealista y por lo tanto, carente de uso práctico.

La mejor forma de decidir el nivel de detalle de un plan es tener un propósito en mente o bien tener presente cada elemento en el plan. Por ejemplo, si estáis considerando añadir recursos al plan, se debe de tener un propósito claro: ¿Cómo los vais a utilizar?, ¿Cómo van a ayudar al proyecto?, ¿Cuánto esfuerzo requiere?, ¿Vale la pena?

Algunas veces, se debe decidir qué elementos se deben incluir en el plan y otras veces la forma en la que quieres planear o preparar algo. Escoge un business case, un acta de constitución de proyecto o un reporte: debes preguntarte a tu mismo la razón por la cual preparas este documento y de qué forma puede ayudar al mismo.

Buscar una plantilla pre-hecha es lo opuesto a realizar algo basado en un propósito.

Ejemplo: Reportar el estado

Es muy común tener reportes de estado muy largos en distintos proyectos. Basándonos en este NUP, tenemos que preguntarnos a nosotros mismos cual es realmente el propósito de reportar y cómo podemos lograr nuestro propósito indistintamente de cómo la gente lleva a cabo sus tareas.

Esto puede, en muchos casos, llevarnos a preparar reportes muy simples y limpios de una página que los interesados pueden leer y entender de forma clara, en vez de los tradicionales reportes con gran cantidad de páginas. Esto es prestar atención al propósito.

Sin embargo, si preparas reportes de una página, algunas personas pueden pensar que no tienes un sistema de control “adecuado” establecido. Esto prácticamente crea un segundo propósito para ti (aparte del primero, que es ayudar a los interesados a entender el estatus del proyecto), y para satisfacerlo, puedes crear simplemente un segundo tipo de reporte que sea muy extenso. Sin embargo, no es recomendable mezclarlos entre sí, porque su propósito es distinto.

Ejemplo: Business case y acta de constitución del proyecto

Preparar documentos como estos es considerado generalmente aburrido, sin sentido, una necesidad burocrática para la mayor cantidad de personas, siendo el caso de que todos estos documentos tienen, de hecho, un propósito valido para la mayoría de los proyectos.

Si intentas encontrar una plantilla pre-hecha y rellenarla, este trabajo simplemente no tiene sentido. En cambio, podrías experimentar el propósito real de estos documentos, analizando cómo son útiles para tu proyecto y luego preparar un documento en la forma que desees, solo para satisfacer los propósitos existentes: ése es el documento correcto.

Mientras piensas la forma en la cual debes preparar estos documentos para satisfacer los propósitos establecidos, tal vez no pienses en el escenario y puedas dejar algo de lado. Para evitar esto, puedes consultar los recursos sugeridos en PRINCE2®, la Guía Del PMBOK®, y DSDM®, y evaluarlos de basado siempre en los propósitos.

Ejemplo: Después del proyecto / Post-Project

Mientras que el proyecto tiene un propósito definido y debe ser considerado a lo largo de todo el proyecto, la realización del propósito esta mayormente basada en pronósticos realizados durante el proyecto. No debemos olvidarnos de esto cuando el proyecto se da por finalizado. Es importante comparar la realización de los objetivos una vez finalizado el proyecto, ya que:

  • Podemos inspeccionar como los objetivos globales son realizados y aprender de ellos en futuros proyectos y,
  • muchas veces, los objetivos son logrados solo cuando realizamos algunas tareas adicionales una vez terminado el proyecto. Para entender la necesidad de aquellas tareas adicionales, se requiere control.

El control una vez finalizado el proyecto es un paso necesario y está basado estrictamente en el propósito. Es una de las responsabilidades principales de los sistemas de gestión de programas y portfolios, que muchas veces es inexistente en las organizaciones, y por lo tanto, ignorada. Por esta razón, metodologías como y DSDM® añaden este paso a su metodología de gestión de proyectos.

Ejemplo: Mantener las cosas simples

En este mundo complejo y caótico, nuestros modelos son aproximaciones abstractas que reflejan partes del mismo. Sin embargo, estos pueden ser simples. Además, los sistemas simples suelen trabajar mejor, ya que permiten concentrarnos en la idea principal.

Muchas de nosotros tratamos de lograr mejores resultados a cambio de añadir complejidad a nuestros sistemas, deseando que estos coincidan con la complejidad del mundo, aunque esto signifique que el sistema se vuelva complejo, de difícil gestión y que usualmente nos impida lograr el propósito principal.

Ejemplo: Adaptación

Los proyectos varían entre sí. Una pieza de software para publicar música por internet tiene una condición muy distinta que una pieza para un equipamiento de un hospital o un avión, donde la vida de mucha gente depende de ello, o de un software que será utilizado en un satélite que se supone tiene que funcionar muchos años sin fallar. Todos ellos, a su vez, son distintos de, por ejemplo, la construcción de una residencia de verano, una estación de bomberos o una planta de procesamiento.

Cuando tienes claro los propósitos, podrás lograr un mejor entendimiento de cómo adaptar los sistemas y los artefactos para los distintos proyectos que gestiones.


Utilizamos elementos replicables

Un enfoque personalizado del proyecto consume muchas energías y recursos, sin olvidar el riesgo latente de dejar de lado ciertos elementos necesarios. La mejor forma de simplificar lo que tiene que hacerse es utilizar elementos que sean replicables, y preferiblemente, utilizarlos en ciclos que a su vez sean replicables.

Ejemplo: Checklists/Cuestionarios de Calidad

Un checklist es simplemente un potencial elemento replicable que muchas personas pueden utilizar tanto a nivel profesional como a nivel personal. Escoge unos indicadores de calidad para el entregable:

  • Primero, debes crear un checklist con todos los criterios, que sería una especie de planning.
  • Lo que NUP6 recomienda, es intentar generalizarlo: ¿Existen otros entregables similares en el proyecto? En ese caso, prepara un cuestionario general de calidad para esa categoría de entregables y añade unos ítems extra para los entregables individuales. Ahora sí que tienes un checklist replicable.
  • Cuando preparas Checklists genéricos para diferentes tipos de entregables, puedes encontrar elementos que se repiten entre ellos, lo que sugiere una filiación virtual entre ellos. En este caso, en vez de repetir los elementos para todas las listas genéricas, extráelos y crea un solo checklist, basándote en la filiación virtual. Finalmente, puede que termines con un solo checklist genérico para todo el proyecto.

La definición de hecho en Scrum es un ejemplo de Checklists a nivel de proyecto para calidad (posiblemente también tiene otros usos). Al realizar esto, cada entregable pertenece a una jerarquía de categorías y tiene que satisfacer los ítems que aparecen en los Checklists de todas las categorías en su jerarquía.

Al realizar esto, un ítem dentro de una filiación virtual se convertirá en replicable para todos los entregables debajo de él, lo que ahorra tiempo y energía en planear y ejecutar. Lo que es todavía más importante, es que, una vez que realices esta tarea para un proyecto, puedes adaptarlo y utilizarlo para todos aquellos proyectos similares que gestiones en un futuro, lo que redunda en una forma replicable para planear proyectos de forma simultánea.

Ejemplo: Procesos y flujos de trabajo

Algunos entregables u objetivos, requieren de ciertas etapas que puedan estandarizarse y replicarse. Por ejemplo, si los entregables deben ser designados de forma individual y ser aprobados, puedes preparar un simple flujo de trabajo que agrupa todas las etapas, la gente involucrada y de forma aproximada establecer la duración de cada una de ellas, y evitar así potenciales conflictos. Debemos ser cautelosos, sin embargo, de no realizar procesos y flujos de trabajo muy complejos o con mucha documentación que realizar, ya que pueden tener efectos negativos.

Toda la gente envuelta en un proyecto debe encontrar un apoyo en los procesos y flujos de trabajo, y debe sentir que éstos ciertamente hacen el trabajo más llevadero y no son solo parte de un sistema burocrático que bloquea su trabajo “real”.

Los proyectos gestionados bajo metodologías agiles, en la práctica cuentan con objetos replicables en su enfoque de desarrollo iterativo, cuando cierto tipo de actividades de desarrollo son replicadas en cada funcionalidad. Por ejemplo, en la metodología XP (eXtreme Programming): Escoger un item, diseñarlo en una pizarra, construir los scripts para testearlo y el código, integrar código, etc.

De la misma forma en que los flujos de trabajo repetitivos que pueden ser utilizados para llevar a cabo tareas técnicas, también se pueden disponer de elementos replicables para gestionar proyectos. Los procesos en la Guía Del PMBOK®, PRINCE2® y DSDM®, las actividades en y los eventos en Scrum son claros ejemplos de estos conceptos.

Ejemplo: Ciclos

Disponer de elementos replicables para gestionar proyectos es útil. Esto puede ser aún más útil si los colocamos dentro de ciclos que también son replicables. Estos ciclos simplifican las actividades diarias de la gente involucrada en gestionar y liderar los proyectos.

Los ciclos de los grupos de proceso en la Guía Del PMBOK® cuando tenemos un proyecto con distintas fases, las etapas en PRINCE2®, las reuniones cíclicas con periodicidad diaria, semanal y mensual en, las iteraciones y los time boxes en DSDM® y los Sprints en Scrum son ejemplos de estos conceptos.

Los ciclos cortos suelen ser más fáciles de entender que los más extensos. Por ejemplo: Los Sprints en Scrum en contraste con las fases expuestas en la Guía Del PMBOK®. Sin embargo, los ciclos que son demasiado cortos, pueden no ser compatibles con ciertos tipos de proyectos. Para estos casos, la solución puede ser utilizar ciclos múltiples, como por ejemplo el uso que DSDM® le da a la duración corta de los ciclos contra mayor duración de la iteración o el uso que le otorga a los ciclos diarios, semanales y mensuales.

Ejemplo: Métodos

Utilizar una metodología o un marco específico para gestionar un proyecto es otro uso de elementos replicables. Esto puede ser un sistema ya existente como PRINCE2®,, DSDM® o Scrum o bien uno que hayáis adaptado o creado a nivel personal. De todas formas, es normalmente una buena idea comenzar con un método ya existente y adaptarlo a vuestras necesidades en vez de construir uno de cero.

Todos los elementos replicables son abstractos y necesitan adaptarse al mundo real. No obstante, hay un espectro de abstracción y una necesidad de adaptabilidad constante: Pequeñas, relativamente concretos Checklists de calidad se encuentran en un extremo de espectro con un nivel bajo de abstracción y necesidad de adaptación, mientras que las metodologías se encuentran en el extremo opuesto, con una necesidad enorme de adaptación.

Siempre debes tener en cuenta lo vital que es llevar a cabo tareas de adaptación, de otra forma, el elemento replicable no podrá satisfacer tus necesidades de forma efectiva.


NUPP - это набор почти универсальных проектных принципов, которым лучше следовать во всех проектах, независимо от используемых методологий и подходов, для достижения максимального если мы хотим добиться успеха.

Каждый из известных подходов и методов для управления проектом опирается на некоторые из этих NUP (почти универсальные принципы). Однако необходимо учитывать следующие моменты:

  • Обычно используются не все принципы, а для практиков было бы полезно рассмотреть все NUP, а не по отдельности.
  • Основополагающие принципы обычно недостаточно разъяснены в подходах и методах, и большинство практиков настолько увлечены практическими деталями, что забывают о принципах и делают вещи, которые несовместимы с ними.

NUPP совместим со всеми основными методами, системами, подходами и фреймворками, такими как PRINCE2®, PMBOK® Guide,, PM², DSDM®, XP, and Scrum. Однако это может быть несовместимо с определенными интерпретациями этих систем, и именно здесь NUPP пытается побудить практиков пересмотреть свои интерпретации.

NUPP - это коллекция следующих NUP:


NUP1: выбирай результаты и истину, а не привязанности

У всех нас есть естественное стремление принадлежать к группам, стремление, которое зачастую выходит за рамки изначальной формы, создает прочные связи и вызывает проблемы. Из-за привязанностей мы теряем намного больше, чем находим. Не ограничивая свою идентичность и взгляды привязанностями, мы можем добиться больше как профессионалы.

Пример: Agile vs Waterfall

Группа энтузиастов, достаточно смелых, чтобы попробовать адаптивные подходы в ИТ в то время, когда нормой было использовать предиктивный, собрались вместе и назвали свой подход «Agile». Это была отличная инициатива: не ограничивать свой выбор тем, что казалось обязательным. В Agile сообществе по-прежнему много энтузиастов и людей, ориентированных на результат, но, к сожалению, есть люди, превращающие Agile в культ и считающие всех вокруг врагами. Это вызывает проблемы, например:

  • Это не позволяет им учиться у кого-либо за пределами их группы
  • Это мешает посторонним учиться у них
  • Это делает принадлежность к группе важнее реальных целей, что, в свою очередь, мешает многим ее членам узнать истинное значение Agility.

Эту проблему можно существенно снизить или полностью убрать, если использовать термин «Agile» в отношении подхода к разработке, а не сообщества; и если люди, считающие себя создателями, решателями проблем и лидерами, будут рассматривать Agile как один из инструментов, а не как свою идентичность

Для настоящих профессионалов не существует войны между Agile и Waterfall.

Пример: PRINCE2® vs PMBOK® Guide

В сообществе есть много профессионалов, которые связывают себя с PRINCE2® или PMBOK® Guide (обычно из-за своего географического положения) и не знакомы с другими подходами. У всех нас могут быть предпочтения в отношении определенных инструментов, но не стоит себя с ними идентифицировать - важнее ознакомиться со всеми, чтобы расширить наши горизонты и возможности выбора.

Настоящий профессионал открыт для всех идей, ищет их, изучает их и использует, когда требуется, вне зависимости от привязанностей.

Пример: непрерывное обучение

Привязанности удовлетворяют человека чувством принадлежности, которое они порождают, но не заставляют, а иногда даже мешают ему учиться из-за страха потерять это чувство. Если вы свободный человек, эксперт без привязанностей, вам необходимо заполнить пробел обучением - непрерывным обучением.

То, что мы знаем сегодня, не является истиной в последней инстанции. Это только наше понимание истины в моменте, которое нужно улучшать, двигаясь вперед. Если ваши взгляды за несколько лет вообще не поменялись, что-то пошло не так. Это верно и в случае с NUPP: если вы вернетесь через несколько лет и увидите всё то же самое, у вас должно закрасться сомнение.

Пример: открытость

Возражая кому-то, убедитесь, что ваши возражения направлены на идею, а не на человека. Это поможет снизить напряженность. Аналогично, когда кто-то возражает вам или против вас, постарайтесь не принимать это на свой счет, сфокусируйтесь на обсуждении идей и оставайтесь открытыми для них. Не слушайте, чтобы ответить, а слушайте, чтобы понять; работайте с другими над идеей, чтобы сделать ее лучше.

Некоторые люди могут преднамеренно нацеливаться на вас, а не на обсуждение идеи, и в этом случае вы должны помочь им сфокусироваться на ней, а не на вас, прежде чем продолжить. Постарайтесь сохранить эту сфокусированность в течение всего разговора.


NUP2: береги и оптимизируй энергию и ресурсы

Ресурсы ограничены. Ресурсы, доступные для проекта, ограничены, так же как и умственная энергия, необходимая для принятия правильных решений. Вы должны беречь и оптимизировать этот ресурс для себя и для проекта, и помогать другим членам команды делать то же самое.

Пример: правило 80/20

Большую часть возможных выгод от управления проектами можно получить, потратив небольшую часть усилий. В большинстве случаев стремление к получению 100% возможных выгод слишком дорого и неоправданно. Учитывайте это правило во всем, что делаете и побуждайте к этому других.

Пример: усталость от принятия решений

Мы используем один источник умственной энергии для принятия всех типов решений, а также для проявления силы воли. Если использовать его для принятия ненужных или неважных решений, у вас будет меньше энергии для важных решений, что приведет к неудовлетворительным результатам. Это одна из причин, по которой лучше избегать микроменеджмента (принцип PRINCE2® «управление по исключениям»).

Конфликты, связанные с идеями, могут быть полезны, но конфликты, связанные с людьми, обычно вредны для проекта, и одно из последствий заключается в том, что это истощает умственную энергию членов команды. Если вы заметили такой конфликт, сделайте всё возможное, чтобы найти причину и устранить ее.

Пример: береги себя!

Решения, которые вы принимаете, и сила воли, которую вы выражаете, расходуют вашу умственную энергию. С другой стороны, энергия восполняется, когда вы спите и правильно питаетесь. Значит, вы должны хорошо заботиться о себе: убедитесь, что у вас достаточно сна и отдыха, и хорошо питайтесь. Если у вас есть вредные привычки или проблемы со сном, не стоит бороться с ними в одиночку. Есть много специалистов, готовых помочь решить такие проблемы. Физическая активность также может помочь восполнить энергию, хотя исследования на тему не дают однозначных выводов.

Побуждайте членов команды делать то же, что и вы. Во-первых, убедитесь, что они работают в устойчивом темпе и без лишних переработок. Если у вас есть возможность, предлагайте питательную здоровую еду и напитки в рабочее время.

Пример: баланс между работой и личной жизнью

Многие из нас любят свою работу, но это еще не все, что нам нужно в жизни. Точно так же, как вы оптимизируете свою работу, вы должны планировать и реализовывать идеи в своей личной жизни таким образом, чтобы она была радостной и счастливой. Когда вы счастливы в жизни, вы более успешны и на работе. Если можете, попытайтесь побудить членов вашей команды поступать так же.

Пример: мотивация

Мотивация – сложная концепция. Есть несколько интересных и полезных ресурсов по этой теме, в том числе и ненаучных. Тем не менее, полезно узнать больше о мотивации и стараться постоянно применять в работе, так как это увеличивает умственную энергию команды и возможность достижения лучших результатов для проекта.

Мотивация может принимать такие простые формы как улыбка и “спасибо” в знак признания работы. Обратите внимание, что некоторые из распространенных форм мотивации, например, небольшие денежные вознаграждения, могут дать отрицательный эффект.

Пример: сотрудничество и командная работа

Сотрудничая, люди могут добиваться лучших результатов, но что еще важнее, мы по своей природе общительны и любим быть частью группы. Если вы сможете устранить негативные аспекты командной работы и создать благоприятную обстановку, ваша команда станет счастливее.

Вы должны быть осторожны, потому что люди разные, и некоторым нужно проводить больше времени в тишине и уединении - необходимо соблюдать баланс.

Пример: культура одной команды

Разные заинтересованные стороны имеют тенденцию группироваться, что вызывает напряженность в отношениях с другими группами; например, люди, которые сосредоточены на бизнес-аспектах проекта vs люди, которые создают продукт. Это напряжение потребляет много энергии с обеих сторон, и это одна из причин, по которой мы должны попытаться создать культуру одной команды, где все работают вместе для достижения одной цели.

Пример: мудрость толпы

Когда большое количество людей с разным опытом и взглядами собираются вместе и работают в благоприятной среде, есть потенциал для получения очень хороших результатов, идей и решений, которые могут быть даже лучше, чем те, что приходят от отдельных экспертов.

Если у вас есть такая возможность, регулярно привлекайте членов команды к решению сложных вопросов в проекте. Помимо возможности получения хороших результатов, это также дает понять членам команды, что их мнение ценится и что они играют важную роль в проекте, что, в свою очередь, повышает их уровень энергии. Шаг № 26 из является примером использования мудрости толпы в проектах.

Пример: главный фасилитатор проекта

Если вы менеджер проекта, большая часть вашей работы имеет характер фасилитации (или, по крайней мере, должна иметь). С другой стороны, вы можете видеть, что члены команды в прошлом имели негативный опыт работы с менеджерами проектов, и что этот опыт влияет на их отношения с вами: вместо доверия часть их энергии расходуется на анализ вашего поведения на предмет потенциальных угроз. В таком случае вы можете изменить свою должность с руководителя проекта на главного фасилитатора проекта. В конце концов, это то, что вы действительно делаете в проекте.


NUP3: всегда будь проактивен

Мы склонны быть реактивными, а не проактивными. Это может помочь нам сохранить нашу энергию при решении второстепенных задач, или может дать нам лучшие результаты, когда мы имеем дело с чем-то, в чем мы совершенно некомпетентны. Эти ситуации отличаются от наших проектов, и здесь мы можем добиться лучших результатов, проявив инициативу.

Пример: планирование

Если вы решили куда-то поехать и уже опаздываете, можно выехать сразу, чтобы «сэкономить время», а возможные проблемы решать по мере их появления. Проактивный подход состоит в том, чтобы потратить некоторое время и сначала построить самый быстрый маршрут, учитывающий пробки, вероятные аварии и перекрытия, а только затем ехать; это займёт время, но в итоге вы его сэкономите, избежав проблем.

В противоположность тому, что некоторые люди думают об Agile проектах, планирование необходимо всегда, и оно зависит только от типа и уровня детализации. Планирование перед выполнением является проактивным подходом.

Запомните выражение: дайте мне шесть часов, чтобы срубить дерево, и первые четыре часа я буду точить топор.

Если это предиктивный проект, вы можете потратить 4 часа на заточку своего топора, потому что вы уверены, что собираетесь срубить дерево. В Agile проекте вы не уверены, собираетесь ли вы рубить дерево, собирать сломанные ветви, стричь газон, добывать уголь или делать что-то еще. Тем не менее, вам все равно нужно подготовиться к этим работам в целом (узнать, где ближайший магазин инструментов) и подготовиться к конкретным работам (заточить топор), когда вы выберите конкретное решение - это тоже планирование.

Пример: планирование планирования

Планирование того, как мы собираемся выполнить проект, является проактивным подходом. Такая проактивность может быть даже расширена путем планирования того, как мы будем планировать выполнение. Это план управления проектом из Руководства PMBOK®, стратегия управления PRINCE2® и подходы в DSDM®.

Пример: непрерывное планирование

Реальность редко соответствует тому, что мы запланировали, и это нормально, но мы должны постоянно адаптировать наши планы, чтобы они оставались реалистичными и практичными. Мы должны делать это сразу, как только требуется корректировка, а не когда мы уже столкнулись с проблемами. Это проактивный подход.

Пример: управление рисками

Вся концепция управления рисками основана на проактивности: сталкиваясь с неопределенностью, мы не ждем, что произойдет, чтобы затем отреагировать, а заранее думаем о возможностях и последствиях, рассматриваем меры реагирования и, вероятно, что-то предпринимаем до того, как риск реализуется.

Помните, что то, что мы делаем в проектах, серьезно, иногда это затрагивает чьи-то жизни.

Пример: определение ролей и обязанностей

Вы можете оставить членов проектной команды работать без четких ролей и обязанностей, и рано или поздно появится форма ролей и обязанностей, но это будет слишком дорого и, в конце концов, может не сработать. Проактивный подход состоит в том, чтобы определить роли и обязанности на ранней стадии и адаптировать их по мере необходимости. Это облегчит работу для всех, и поможет сосредоточиться на создании продукта, вместо того, чтобы решать, кто чем занимается.

Количество и разнообразие ролей зависят от типа и размера проекта; их набор может быть строго определен, как, например, в Scrum, умеренно, например, в, или всеобъемлюще, как в DSDM® и PRINCE2®. Однако не забывайте, что описания ролей в этих методах касаются только управленческих аспектов, – вам всегда нужно добавлять описания ролей и для техническимих аспектамиов.

Пример: доступные варианты

Стоит ли преждевременно закрыть проект или продолжить?

Очень редко у нас действительно есть только два варианта, даже если вопрос подразумевает это. Вам нужно проявлять проактивный подход и обдумать все варианты, прежде чем принимать решение. Может быть, вы можете изменить содержание проекта; возможно, вы можете приостановить его, пока что-то еще не станет ясным; или, может быть, вы можете изменить подход к проекту (например, отдать его на аутсорсинг) и т. д.

Пример: критическое мышление

У всех нас много предубеждений, которые, с одной стороны, помогают нам выживать, а с другой – приводят к некачественным решениям. Принимая важные решения по проекту, лучше всего взять паузу и рассмотреть все предубеждения, которые могут повлиять на наше решение, прежде чем они вызовут проблемы.

В качестве ссылки вы можете использовать список когнитивных искажений, приведенный в Википедии:

Существуют даже специальные фреймворки, которые вы можете использовать для получения качественных решений. Поначалу их использование может отвлекать и даже раздражать, но вскоре вы привыкаете к ним и получаете преимущество от их применения без особых сознательных усилий.

Пример: прозрачность

Нам не нравится срывать сроки или сталкиваться с другими проблемами, но это не значит, что их нужно скрывать. Вы должны сохранять прозрачность и открыто сообщать о проблемах стейкхолдерам, потому что некоторые из них могут вам помочь, и, кроме того, рано или поздно они в любом случае узнают о проблемах и их последствиях, а от некоторых из них могут потребоваться скорейшие действия (например, принять негативные последствия).

Пример: общаться эффективно

Бывает, что вы отправляете отчеты и не получаете обратной связи. Вы можете подумать, что все в порядке только потому, что отрицательных отзывов нет, хотя это может быть и не так. Вы должны быть проактивны и проверять, ознакомились ли они с отчетом и послужил ли он своей цели, и использовать эту информацию для совершенствования коммуникаций; в противном случае, эта скрытая проблема может вызвать серьезные проблемы позже, когда её будет слишком трудно исправить.

Пример: берите на себя ответственность

Легко обвинять других в плохих результатах. Например, вы хотите, чтобы ваша организация предоставила вам карт-бланш, и чтобы вы сделали проект идеально, но они этого не делают, и в результате проект терпит неудачу. Это не проактивный подход.

Проактивный подход заключается в том, чтобы взять на себя ответственность и делать все возможное в рамках существующих ограничений. Не стоит ожидать, что организация полностью вам доверяет и даст зеленый свет в надежде на лучшие результаты, особенно если они уже видели неудачные проекты. Сделайте одно небольшое улучшение в рамках существующих ограничений и используйте это, чтобы завоевать доверие, получить немного больше ресурсов и терпения, а затем используйте это для чуть большего улучшения и так до тех пор, пока не достигнете своей цели.


NUP4: помни, что прочность цепи определяется по самому слабому звену

Проекты состоят из различных доменов, и все они требуют внимания; у нас должна быть целостная картина проекта. Недостаточно обратить внимание на, казалось бы, самую важный домен (например, сроки), потому что все домены взаимосвязаны и не работают должным образом без достаточного внимания.

Пример: это всё о дедлайне!

Допустим, вы строите что-то для Олимпийских игр. У проекта очень строгий дедлайн, что делает управление сроками очень важным. Так ли это?

Что, если качество настолько низкое, что через некоторое время требуется повторная работа. Это повлияет на время, значит, нужно уделять внимание качеству и срокам. У вас может быть причудливый сад, указанный в первоначальном определении проекта, но вы знаете, что если не хватает времени, вы можете не выращивать его и просто заменить газоном, если вы вовремя рассмотрели эту возможность и подготовились к ней. Таким образом, управление содержанием также важно. Теперь содержание, время и качество в центре нашего внимания.

Вы слышали о знаменитом случае, когда президент Кеннеди встретил уборщика в NASA и спросил его, что он делает? Уборщик ответил: «Я помогаю посадить человека на Луну». Разве такие люди в проекте не помогают выполнить его в срок?

Продолжая, вы замечаете, что каждый отдельный домен в проекте способствует управлению сроками, и вы не можете уложиться в срок с приемлемым уровнем вероятности, если не уделяете внимание всем доменам.

Пример: выборочные заимствования

Когда люди сталкиваются со множеством методов, иногда они начинают делать выборочные заимствования из разных систем и создают смесь всего, что кажется им интересным. Это обычно не работает, потому что элементы не работают изолированно и должны быть совместимы друг с другом. Любые дополнения или изменения в системе должны быть сделаны с комплексной точки зрения.

Вот почему мы иногда видим противоречивые элементы в разных подходах; что-то хорошо работает в одном, а его противоположность хорошо работает в другом. Сами по себе эти элементы не являются ни правильными, ни неправильными.

Самый безопасный подход - это выбрать методологию для проекта, адаптировать ее, а затем осторожно добавить к ней новые элементы, учитывая целостность всей системы.

Пример: антипроцессный подход

Одна из лучших вещей, которую сделали Agile-методы, – привлечение внимания к человеческим аспектам. Agile Manifesto дает бОльшую ценность личностям и их взаимодействию по сравнению с процессами и инструментами, хотя это может и не быть справедливым сравнением. Почти все подходы признают важность человеческого аспекта, но именно в аджайл они встроены в процессы, а не являются просто рекомендацией. Таким образом, речь идет не о конкуренции между человеческими аспектами и процессами, а скорее о том, как они рассматриваются в системе.

Нет сомнений в том, что некоторые пытаются заменить человеческие аспекты усложненными процессами, но это всего лишь злоупотребление. Существует также и обратная проблема: люди пытаются заменить процессы человеческими аспектами, что также не очень хорошо работает.

Пример: вам нужны все домены

Когда вы думаете о доменах, будьте осторожны, чтобы не пропустить ни один из них. Кстати, что это за домены? Если вы проверите основополагающие ресурсы, вы получите разные ответы; и все же, ни один из них не является полной правдой.

Темы PRINCE2® - это домены, но это только те домены, которые играют ключевую роль в методологии. Другие домены только подразумеваются. Руководство PMBOK® не является методологией и может сформулировать ответ гораздо лучше с помощью десяти областей знаний. Однако это интерпретации всех доменов, основанные на точке зрения руководства PMBOK® на проект, а не на нейтральной (нейтральная точка зрения существует не всегда). Например, человеческие аспекты не получают большого внимания в Руководстве PMBOK®.

Хорошим источником информации о доменах является ICB. Однако здесь речь идет не о доменах, а о компетенциях, которые требуются в проекте. У них нет однозначных сопоставлений с доменами, но это очень помогает в их идентификации. В NUPP нет списка доменов, в первую очередь потому, что это скорее метасистема, чем система, а также потому, что категоризация доменов зависит от типа проекта и его среды; например, рутинный строительный проект может нуждаться в ином подходе, чем творческий исследовательский проект.


NUP5: не делай ничего без четкой цели

Вы не должны ничего делать, если это не имеет четкой цели. Представьте себе два параллельных мира, в которых все одинаково, за исключением того, что вы планируете делать: насколько разными будут эти миры? Разве разница стоит усилий, чтобы сделать это?

Если у вас нет ясной цели и вы делаете что-то только потому, что это делают все остальные, или все говорят, что это важно, то

  • это может не принести вам реальной пользы, и, следовательно, вы можете ничего не получить от этого;
  • или же в вашем случае он все еще может иметь потенциальные выгоды, но поскольку у вас нет этой цели, ваш способ сделать это может не помочь реализовать преимущества.

Пример: портфолио и программы

Если вы участвуете в отборе и запуске проектов, убедитесь, что вы сосредоточены на решаемых проблемах и создаваемых преимуществах, а не на технических решениях. Классическим примером является производитель лифтов, который получая жалобы на скорость своих лифтов, запустил несколько проектов по увеличению скорости без особого успеха. Это продолжалось до тех пор, пока они не решили сосредоточиться на проблеме (скука или дискомфорт людей) вместо «естественного» решения (более быстрые лифты). В результате они добавили зеркала в лифты, и это решило проблему просто и дешево.

Помните, что управление проектами - это в основном правильные действия, а управление портфелями - правильные вещи. Неважно, насколько хорошо вы управляете своими проектами; это не сработает, если вы делаете неправильные проекты. Всё это о наличии цели.

Пример: проект в целом

Гибкость продукта варьируется между проектами. В некоторых проектах по развитию ИТ продукт является полностью гибким, и его окончательная форма зависит от обратной связи, которая будет генерироваться по инкрементам продукта в ходе проекта, что требует применения адаптивного (гибкого) подхода. На практике это комбинация уровней портфеля, программы и проекта и требует максимального внимания к конечной цели. Рекомендуется задокументировать цель и сделать ее доступной; это одна из целей «видения продукта», которое используется в некоторых проектах Scrum. Внимание к бизнес ценности в Agile проектах - это их способ обеспечить соответствие цели.

В других типах проектов, где продукт является относительно фиксированным и существуют другие механизмы, гарантирующие, что конечный продукт будет удовлетворять цели, члены проектной команды могут перенести большую часть своего внимания с цели на продукт ( следовательно, принцип «сосредоточить внимание на продуктах» (PRINCE2®)), но все же требуется по крайней мере минимальное внимание цели, чтобы гарантировать, что то, что строится, будет соответствовать цели, что можно сделать путем сравнения прогнозируемых выгод с ожидаемыми (принцип «постоянная оценка целесообразности» и тема «экономическое обоснование» в PRINCE2®).

Когда проект запускается для внешнего клиента, у клиента будет своя цель проекта, а у вас своя. Чтобы преуспеть, вам нужно понимать обе.

Пример: мониторинг проекта

Необходимо сосредоточиться на конечной цели, но она может быть слишком абстрактной для многих повседневных задач. Вот почему для эффективной работы необходима иерархия целей. Сначала обоснование и выгоды проекта определяются на основе конечной цели, а затем у вас появляются явные и неявные цели для переменных проекта (например, сроки, стоимость и качество), достигая которые вы, в свою очередь, удовлетворяете конечную цель. Это цели более низкого уровня, которые полезны для многих наших повседневных задач.

Когда дело доходит до мониторинга, низкоуровневый мониторинг проекта будет осуществляться с использованием самого низкого уровня переменных, поскольку отследить конечную цель не всегда возможно. В этом случае держите в уме: какая цель мониторинга?

Нормальный и приемлемый ответ - посмотреть, находимся ли мы на правильном пути, и если нет, совершить определенные действия, чтобы вернуться в прежнее русло, или скорректировать цели и посмотреть, сможем ли мы по-прежнему достигнуть конечную цель. Поэтому наши измерения должны быть в состоянии помочь справиться с этой низкоуровневой задачей, а также сформировать прогноз по завершении для переменных проекта; например, когда мы сможем завершить проект? Сколько денег нам понадобится, чтобы закончить проект?

Все остальные измерения, такие как плановые и фактические значения на сегодняшний день, являются лишь промежуточными значениями, которые вам нужны для расчета прогнозов, а не окончательными значениями, которые вы используете для управленческих целей.

Пример: документы

Независимо от того, какой подход к разработке вы используете в проекте, планирование всегда необходимо. Важным вопросом является уровень детализации каждого типа плана. Если в плане недостаточно подробностей, план не сможет внести достаточный вклад, и выполнение проекта будет основано на спонтанных решениях, а не на комплексных, целостных решениях. С другой стороны, многие люди стараются быть осторожными и добавляют слишком много деталей к своему плану, что делает его слишком сложным для подготовки и сопровождения и слишком жестким для неопределенности проекта. В результате план становится нереальным и бесполезным.

Лучший способ определить уровень детализации - это иметь цель для каждого элемента в плане. Например, если вы рассматриваете возможность добавления ресурсов в план, у вас должна быть для этого цель: как вы собираетесь его использовать? Как это поможет проекту? Сколько усилий это займет? и стоит ли это того?

Иногда нужно решить, хотите ли вы иметь определенный элемент в своих планах, а иногда - то, как вы хотите спланировать или подготовить что-то. Будь то экономическое обоснование, устав проекта или отчет: вы все равно должны спросить себя, почему вы готовите этот документ и как он может помочь проекту.

Поиск «шаблона» - это противоположность тому, чтобы делать что-то на основе цели.

Пример: статус-отчеты

По проектам часто формируют действительно длинные статус-отчеты. Основываясь на этом NUP, мы должны спросить себя, какова цель отчета и как мы можем достичь этой цели независимо от того, как поступает большинство других людей.

Это может привести к тому, что мы начнём формировать очень простые одностраничные отчеты, которые заинтересованные стороны действительно прочитают и поймут, в противоположность длинным. Это означает внимание к цели.

Однако когда вы готовите одностраничные отчеты, некоторые люди могут возражать и думать, что у вас нет «надлежащей» системы мониторинга. На практике это создает для вас вторую цель (помимо первой цели – помочь заинтересованным сторонам понять статус проекта), и чтобы удовлетворить её, вы можете просто создать второй тип отчета, который будет очень длинным. При этом вы не будете смешивать его с первым отчетом, потому что эти две цели не совпадают.

Пример: бизнес-кейс и устав проекта

Подготовка документов, таких как бизнес-кейс и устав проекта, обычно является скучной, бесплодной, бюрократической необходимостью, в то время как все эти документы имеют обоснование и применимы к большинству проектов. Если вы попытаетесь найти «шаблон» и заполнить его, работа будет просто сделана впустую; тогда как вы можете вместо этого проверить реальное назначение этих документов, посмотреть, могут ли они помочь в вашем проекте и каким образом они могут помочь, а затем подготовить документ так, как вам нравится, просто для достижения этих целей: это будет правильный документ.

Пока вы думаете о том, как подготовить документы для достижения их целей, вы можете забыть рассмотреть все варианты. Чтобы избежать этого, вы можете проверить, что предлагают PRINCE2®, PMBOK® Guide, и DSDM®, а затем оценить эти рекомендации в контексте ваших целей.

Пример: пост-проект

Хотя проект имеет конкретную цель, и мы можем учитывать эту цель на протяжении всего проекта, реализация цели в основном оценивается на основе прогнозов, сделанных в ходе проекта. Однако не следует забывать об этом, когда проект завершен. Важно проверить реализацию целей после завершения проекта, потому что

  • мы можем увидеть, как достигаются конечные цели и извлечь из этого уроки для будущих проектов, и
  • иногда цели достигаются только тогда, когда мы предпринимаем некоторые дополнительные действия после завершения проекта, и понимание необходимости этих дополнительных задач требует контроля.

Постпроектный мониторинг является необходимым шагом для достижения цели. В основном это зона ответственности управления программами и портфелями, и поскольку большинство компаний не имеют таких уровней управления, этим шагом обычно пренебрегают. Вот почему такие методы, как и DSDM®, добавляют этот шаг в свои методологии управления проектами.

Пример: простота

Мир сложен и хаотичен, но наши модели представляют собой абстрактные приближения, которые отражают части мира, и, следовательно, они могут быть простыми. С другой стороны, простые системы обычно работают лучше, потому что мы можем сосредоточиться на основной идее.

Многие из нас пытаются добиться лучших результатов, добавляя сложность к нашим системам, надеясь, что она будет соответствовать сложности всего мира, хотя на практике это затрудняет работу с системой и, как правило, мешает нам достичь цели.

Пример: Адаптация

Программное обеспечение для потоковой музыки очень отличается от ПО, которое будет использоваться для оборудования в больнице или самолете, где от него может зависеть жизнь людей, или от ПО, которое будет использоваться на спутнике, где оно, как предполагается, будет работать много лет без сбоев, всё это отличается от строительства летней дачи, пожарной станции или завода.

Фокусируясь на целях, вы лучше поймете, как адаптировать системы и артефакты для различных проектов.


NUP6: используй воспроизводимые элементы

Спонтанный подход к проекту требует слишком много энергии и ресурсов, и вы всегда рискуете пропустить некоторые из необходимых элементов. Лучший способ упростить работу - использовать воспроизводимые элементы, желательно в повторяющихся циклах.

Пример: чек-листы качества

Чек-лист — простой пример потенциально повторяемого элемента, который многие люди используют и в личной и профессиональной жизни. Возьмите, например, критерии качества продукта:

  • Во-первых, вы можете создать список всех критериев, что уже является формой планирования.
  • NUP6 рекомендует попытаться обобщить их: есть ли другие подобные продукты в проекте? В таком случае сделайте общий чек-лист качества для этой категории продуктов. Если возможны вариации, сохраните общий список и добавьте несколько дополнительных элементов для отдельных продуктов. Теперь у вас есть воспроизводимые чек-листы.
  • После того, как вы подготовите общие чек-листы для различных типов продуктов, вы можете найти повторяющиеся пункты и сделать для них виртуальную родительскую категорию. В этом случае вместо повторения элементов для всех этих общих чек-листов вы можете извлечь их и поместить в родительский чек-лист. В конце у вас, вероятно, будет единый общий чек-лист для всего проекта. «Definition of Done» в Scrum является примером использования чек-листов на уровне проекта для проверки качества (возможно, среди прочего). Таким образом, каждый результат будет принадлежать иерархии категорий и должен удовлетворять элементам, которые появляются в контрольных списках всех категорий в их цепочке.

Таким образом, элемент в родительском чек-листе станет повторяемым для всех результатов, находящихся под ним, что экономит время и энергию при планировании и выполнении.

Что еще более важно, как только вы сделаете это для одного проекта, вы можете адаптировать и использовать его для всех аналогичных проектов в будущем, что является повторяемой формой планирования для нескольких проектов.

Пример: процессы и рабочие процессы

Некоторые продукты или связанные с ними цели требуют стандартизации и воспроизводимости определенных шагов. Например, если продукты должны быть разработаны индивидуально и утверждены, вы можете разработать простой рабочий процесс, в котором будут понятны все этапы, задействованные лица и приблизительная продолжительность, что позволит избежать многих трудностей. Однако следует соблюдать осторожность, чтобы не усложнять процессы, поскольку это будет иметь негативные последствия. Все участники проекта должны рассматривать бизнес-процессы как поддержку и упрощение, а не как бюрократию, мешающую работе.

Гибкие проекты имеют воспроизводимые элементы в своем итеративном подходе к разработке, где определенный тип действий повторяется для каждой фичи; например, обычная ежедневная рутина в XP (экстремальном программировании): объединение в пару, выбор элемента, проектирование на доске, создание сценариев теста и кода, интеграция кода и т. д.

Помимо воспроизводимых процессов, которые можно использовать для технических действий, у вас могут быть повторяемые элементы для действий по управлению проектами. Процессы в Руководстве PMBOK®, PRINCE2® и DSDM®, шаги в и события в Scrum являются примерами этой концепции.

Пример: циклы

Полезно использовать воспроизводимые элементы для управления проектом. Это может быть сделать еще проще, помещая их в повторяющиеся циклы. Эти циклы значительно упрощают повседневную работу людей, вовлеченных в управление и руководство проектом. Циклы групп процессов в Руководстве PMBOK® при использовании в проекте с несколькими фазами, этапами в PRINCE2®, ежедневными, еженедельными и ежемесячными циклами в, итерациями и временными рамками в DSDM® и спринтами в Scrum являются примерами этой концепции.

Более короткие циклы легче понять и использовать, чем более длинные; например, спринты в Scrum в сравнении с фазами из руководства PMBOK®. Однако слишком короткие циклы подходят не для всех типов проектов, решением может быть использование сочетания нескольких типов циклов, например короткие таймбоксы в сочетании с более длинными итерациями в DSDM®, или использование ежедневных, еженедельных и ежемесячных циклов в

Пример: методы

Использование методологии или фреймворка для запуска проекта - еще один пример использования воспроизводимых элементов. Это может быть уже существующая система, такая как PRINCE2®,, DSDM® или Scrum, или система, которую вы настроили или создали самостоятельно. Однако, как правило, лучше начать с одного из существующих методов и адаптировать его к своим потребностям, чем создавать свой с нуля.

Любой повторяемый элемент является абстрактным и нуждается в настройке, чтобы адаптировать его к реальному миру. Тем не менее, существуют разные степени и абстракции и потребности в адаптации: небольшие, относительно конкретные чек-листы качества находятся на одном конце спектра с наименьшим уровнем абстракции и потребностью в адаптации, в то время как методологии находятся на другом конце, с самой высокой потребностью в адаптации. Вы должны всегда учитывать необходимость адаптации, в противном случае воспроизводимый элемент не будет соответствовать вашим потребностям.


NUPP شامل مجموعه‌ اصولی است که برای کسب بهترین نتیجه-ممکن در پروژه ها باید به بهترین شکل ممکن آنها را بکار گرفت، صرفنظر از اینکه کدام متدولوژی‌ یا رویکرد در مدیریت پروژه استفاده میکنیم.

هریک از منابع در دسترس (اعم از نیروی انسانی و متریال و ماشین‌آلات) و متدهای اجرای پروژه به برخی از این اصول NUP (Nearly Universal Principles of Projects) متکی هستند. بااین‌حال، میبایست نکات زیر نیز در نظر گرفته شود :

  • معمولا هیچکدام بر تمام NUPها تاکید نمی‌کنند، در حالی که مد نظر داشتن تمامی آن‌ها برای دست‌اندرکاران پروژه‌ها سودمند است.
  • اصولی که زیربنای روش‌هاست گاهی به شفافیت طرح نشده‌اند و دست‌اندرکاران پروژه‌ها آنقدر مشغول جزئیات روش‌ها هستند که اصول زیربنایی را فراموش می‌کنند و گاهی اقداماتی انجام می‌دهند که با آن اصول ضدیت دارد.

NUPP با همه متدها، سیستم‌ها، منابع و چارچوب‌های اصلی نظیر PRINCE2®, PMBOK® Guide,, PM², DSDM®, XP, Scrum سازگار است. اگرچه ممکن است با تفسیر خاصی از این سیستم‌ها سازگار نباشد. اینجاست که NUPP متخصصین را به تجدید نظر در تفسیرهای خود ترغیب می‌کند.

NUPP مجموعه‌ای از NUP های زیر است:


نتایج و صحت آن‌ها بر وابستگی‌ها و تعصب‌ها مقدم اند

همه ما به‌طور ذاتی تمایل به عضویت در گروه داریم این میل اغلب از شکل اولیه خود فراتر رفته و با ایجاد وابستگی‌های شدید، مشکل‌ساز می‌شود. بدلیل این وابستگیها، بیش از آنکه از عضویت در گروه منفعتی بدست بیاوریم، متضرر میشویم. با محدود نکردن شخصیت و سلایقمان به گروهی خاص، میتوانیم متخصص حرفه ای تر و کارامدتری باشیم.

مثال: شیوه اجرای چابک در برابر آبشاری

زمانی که عرفِ مدیریت پروژه، مدیریت با رویکرد متعین (Predictive Approach) بود گروهی از افراد مشتاق و علاقه‌مند شهامت به خرج داده، گرد هم آمدند تا توسعه با رویکرد تطبیقی (Adaptive Development) را در صنعت IT به‌کارگیرند و آن را چابک (Agile) نام نهادند. این کار ابتکاری بزرگ بود تا خودمان را به مواردی که صرفا در نگاه اول ضروری بنظر میرسند محدود نکنیم. اگرچه هنوز، بسیاری از افراد مشتاق و نتیجه گرا عضو جامعه مدیریت چابک (Agile) هستند اما متاسفانه افراد دیگری نیز در این جامعه هستند که Agile را به یک فرقه تبدیل کرده و کسانی که خارج از این فرقه هستند را دشمن می‌پندارند که این کار مشکلات گوناگونی ایجاد میکند از جمله:

  • مانع یادگیری ایشان از افراد خارج از فرقه می‌شود.
  • دیگران را نسبت به یادگیری از خود دلسرد می‌کنند.
  • اهمیت عضویت در گروه را پر رنگ تر از هدف واقعی گروه جلوه میدهند که به‌نوبه خود مانع یادگیری معنای واقعی چابکی (Agility) برای بسیاری از اعضای گروه می‌گردد. این مشکل تا حد قابل‌ملاحظه‌ای کمرنگ تر شده و یا به‌کلی از بین خواهد رفت اگر:
  • Agile را صرفاً یک عنوان برای اشاره به یک رویکرد توسعه‌ای در نظر بگیریم و نه جامعه‌ای از افراد و اعضا
  • افراد خود را سازنده، حلّال مشکلات (Problem Solver) و رهبری بدانند که Agile را به‌عنوان ابزاری توانمند ساز به همراه خود دارند و نه به‌عنوان هویت یا شخصیت خود

برای افراد حرفه‌ای‌ هیچ نزاعی بین Agile و Waterfall در کار نیست.

مثال: PRINCE2® در برابر PMBOK® Guide

بسیاری از افراد حرفه‌ای در جامعه، خودشان را به یکی از دو رویکرد PMBOK® Guide یا PRINCE2® وابسته می‌دانند (معمولاً به دلیل موقعیت جغرافیاییِ‌شان) و با رویکرد دیگر آشنا نیستند. همه ما می‌توانیم یکی از این دو را به دیگری ترجیح دهیم این سلیقه ماست و نه هویت ما. مهم‌تر اینکه باید تمامی رویکردها را بشناسیم تا افق دید بهتر و حق انتخاب بیشتری داشته باشیم.

یک حرفه‌ای واقعی بدون هرگونه وابستگی و تعصب، تمامی ایده‌ها را با آغوش باز می‌پذیرد، آن‌ها را دنبال کرده و فرامی‌گیرد تا در موقع لزوم از آن‌ها استفاده کند.

مثال: یادگیری مداوم

وابستگی به گروه‌ها، افراد را بااحساس تعلق به گروه اقناع می‌کنند و آن‌ها را مجبور به یادگیری نمیکند و حتی گاهی به دلیل ترس از دست دادن اعضا، آن‌ها را از یادگیری دلسرد می‌کنند. وقتی‌که فردی مستقل و متخصصی بدون وابستگی باشید می‌بایست این خلا را با یادگیری پرکنید، یادگیری مداوم.

آنچه امروز باور داریم، تمامِ حقیقت نیست، بلکه صرفاً بهترین درک ما از حقیقت تا به امروز است که باید به‌مرورزمان بهبود یابد. اگر ایده‌های کسی دقیقاً شبیه ایده‌های چند سال قبل او باشد نشان می‌دهد که یک جای کار اشتباه است. این مورد حتی در مورد NUPP هم صادق است یعنی اگر چند سال بعد به آن مراجعه کردید و دیدید همه چیز کاملا شبیه امروز است باید در آن تردید کنید.

مثال: نقد پذیری

وقتی کسی را نقد می‌کنید اطمینان حاصل کنید که ایده را نشانه گرفته اید، نه شخص ایده پرداز را. این کار مانع بُروز بسیاری از تنش‌ها می‌شود. عیناً زمانی که کسی با شما مخالفت می‌کند یا شما را نقد می‌کند باید سعی کنید آن را به‌عنوان یک جنگ علیه خود تفسیر نکنید بلکه این یک بحث و تبادل‌نظر بر روی ایده شماست و باید از آن استقبال کنید. شنیدن برای پاسخ دادن را کنار بگذارید بلکه بشنوید تا بفهمید و برای بهبود ایده‌تان با دیگران کارکنید.

ممکن است، کسی عمداً خودتان را به‌جای ایده‌تان هدف قرار دهد در آن شرایط پیش از انجام هرکاری، سعی کنید به او کمک کنید تا، به‌جای شما بر روی ایده‌هایتان تمرکز کند و این روند را در طول مکالمه حفظ کنید.


حفظ و بهینه‌سازی انرژی و منابع

همانگونه که منابع در طبیعت محدودند، منابع در دسترس پروژه نیز محدود هستند. از آنجا که انرژی ذهنی شما نیز برای اتخاذ تصمیمات مناسب محدود است، شما باید این منبع را برای خودتان و پروژه حفظ کرده و بهینه مصرف کنید و به سایر اعضای گروه نیز کمک کنید تا این کار را انجام دهند.

مثال: اصل ۸۰/۲۰

80% منافع قابل حصول از انجام فعالیتهای مدیریت پروژه تنها با اندکی تلاش به دست می‌آید. اکثر مواقع دستیابی به 100% مزایای ممکن، بسیار گران‌قیمت و فاقد توجیه اقتصادی است. می‌بایست این قاعده را در تمامی کارهایی که می‌کنید در نظر گرفته و دیگران را نیز به استفاده از این قاعده ترغیب کنید.

مثال: خستگی تصمیم

همه ما برای انواع تصمیم‌گیری‌ها تنها یک منبع انرژی ذهنی داریم، بنابراین اگر بیش از حد این منبع را برای تصمیمات غیرضروری یا کم‌اهمیت استفاده کنیم انرژی کمتری برای تصمیم‌گیری‌های مهم خواهیم داشت که ممکن است باعث کسب نتایج ضعیف گردد. این، یکی از دلایلی است که باید از میکرو مدیریت (مدیریت تمام جزئیات) اجتناب کنید (اصل “Manage by exception” در PRINCE2®)

مناقشات پیرامون ایده‌ها می‌تواند مفید باشد اما مناقشه پیرامون افراد معمولاً برای پروژه مضر است و یکی از تبعات آن کاستنِ انرژی ذهنی اعضای گروه است. اگر با چنین مناقشاتی مواجه شدید باید در راستای ریشه‌یابی و حل آن بکوشید.

مثال: مراقبت از خود

هر تصمیمی که می‌گیرید بخشی از انرژی موجود در منبع انرژی ذهنی‌تان را مصرف میکند. ازطرف دیگر این منبع با استراحت و تغذیه مناسب شارژ می‌شود. پس باید به‌خوبی از خودتان مراقبت کنید. از کافی بودن خواب و استراحتتان و مناسب بودن تغذیه‌تان اطمینان حاصل کنید. اگر عادت‌های مضر یا مشکلات خواب‌دارید، نیاز نیست به‌تنهایی آن‌ها را برطرف کنید متخصصان بسیاری هستند که می‌توانند به شما در رفع این مشکلات کمک کنند. اگرچه تاکنون مطالعات، تأثیر فعالیت‌های فیزیکی بر بهبود این منبع انرژی را تائید نکرده اما احتمالاً این‌گونه فعالیت‌ها نیز بر این منبع انرژی تأثیر مثبتی خواهد داشت.

اعضای گروه را نیز برای انجام اموری مشابه تشویق کنید. ابتدا اطمینان حاصل کنید که آن‌ها با سرعت مناسب و بدون ساعات اضافه‌کاری زیاد کار می‌کنند. سپس سعی کنید درصورتی‌که حق انتخاب دارید از غذا، میان وعده و نوشیدنی سالم و مُقوّی در طول زمان کار استفاده کنید.

مثال: موازنه کار-زندگی

خیلی از ما عاشقانه شغلمان را دوست داریم اما این تمام آن چیزی نیست که ما در زندگی به آن نیاز داریم. همان‌گونه که برای بهتر شدن کارتان تلاش می‌کنید باید برای داشتن زندگی شاد و مفرح برنامه‌ریزی کنید. هرچقدر شادتر باشید می‌توانید در کارتان هم موفق‌تر باشید. اگر می‌توانید سایر اعضا گروهتان را برای انجام اموری مشابه تشویق کنید.

مثال: انگیزه

انگیزه مفهومی پیچیده است. کتب و مقالات جذاب و مفیدِ علمی و غیرعلمی زیادی در رابطه با این موضوع موجود است. به‌هرحال شما باید در این رابطه مطالعه داشته باشید و پیوسته از آموخته‌هایتان استفاده کنید تا انرژی ذهنی گروهتان را افزایش دهید تا احتمال دستیابی به نتایج بهتر در پروژه بالاتر رود . انگیزش می‌تواند به‌سادگی یک لبخند محبت‌آمیز یا یک تشکر ساده برای نشان دادن رضایتتان از کارِ کارکنان باشد. اگرچه باید مراقب باشید که بسیاری از اَشکال رایج برای انگیزش از قبیل پاداش‌های کوچک مالی تأثیرات منفی دارند.

مثال: تشریک‌مساعی و کار تیمی

گاهی ممکن است افرادی که باهم همکاری می‌کنند بتوانند نتایج بهتری خلق کنند اما مهم‌تر آن است که بشر موجودی اجتماعی است و از اینکه عضوی از یک گروه باشد لذت می‌برد. اگر بتوانید جنبه‌های منفی کار تیمی را از بین ببرید و محیط دلپذیری ایجاد کنید اعضای گروه شما در پروژه شادتر خواهند بود.

به تفاوت افراد توجه کنید، برخی نیاز به آرامش بیشتر، تمرکز بیشتر و زمان‌های تنهایی و خلوت بیشتر نسبت به دیگران دارند و باید تعادل را در این زمینه برقرار کرد.

مثال: فرهنگ تیم واحد

ذینفعان مختلف تمایل به ایجاد گروه بندی های مختلف برای ایجاد فشار و تنش بر سایر گروه‌ها دارند؛ مثلاً: افرادی که بر روی جنبه‌های کسب‌وکار پروژه تمرکز دارند در مقابل افرادی که محصول را می‌سازند. این تنش‌ها انرژی زیادی از دو طرف می‌گیرد، این که یکی از دلایلی است که باید تلاش کنیم افرادی که برای هدف مشترکی کار می‌کنند از فرهنگ تیم واحد پیروی کنند.

مثال: خرد جمعی

وقتی تعداد زیادی افراد مختلف گرد هم جمع می‌شوند تا کاری را انجام دهند پتانسیل دستیابی به نتایج، ایده‌ها و راه‌حل‌های بسیار خوب وجود دارد که حتی ممکن است بهتر از نتایجی باشد که از یک متخصص به‌تنهایی حاصل شود.

اگر این امکان را دارید می‌توانید مرتباً از اعضای تیم بخواهید تا برای حل مسائل سخت موجود در پروژه به شما کمک کنند. علاوه بر امکان دستیابی به نتایج بهتر، این کار به اعضای تیم نشان میدهد که نظرشان ارزشمند است و آن‌ها نقش مهمی در پروژه ایفا می‌کنند که به‌نوبه خود سطح انرژی‌شان را افزایش می‌دهد. فعالیت #26 در مثالی از استفاده از خرد جمعی در پروژه‌هاست.

مثال: تسهیل‌کننده ارشد پروژه

اگر شما مدیر پروژه هستید اغلب کارهایی که شما انجام می‌دهید از جنس تسهیل‌کنندگی است (یا حداقل باید این‌گونه باشد). از سوی دیگر ممکن است اعضای تیم تجربه ناخوشایندی از مدیریت پروژه درگذشته داشته باشند و آن تجربه ناخوشایند روی روابطشان با شما تأثیر گذاشته و بخشی از انرژی آن‌ها بجای آنکه صرف اعتماد به شما شود، صرف تحلیل رفتار شما به‌عنوان یک تهدید بالقوه شود. در این شرایط می‌توانید عنوان خودتان را به «تسهیل‌کننده ارشد پروژه» تغییر دهید چون درنهایت این کاری است که واقعاً در پروژه انجام می‌دهید.


همیشه غیرانفعالی رفتار کنید

همه ما به‌طور طبیعی تمایل به منفعل بودن (Reactive) داریم. انفعال در مواجهه با مسائل کم‌اهمیت می‌تواند به ذخیره کردن انرژی‌مان کمک کند، یا زمانی که باکارهایی مواجهیم که در آن صلاحیت لازم را نداریم به نتایج بهتری بیانجامد. اما شرایط پروژه‌هایمان اینگونه نیست، در پروژه‌ها زمانی به نتایج بهتری می‌رسیم که غیر انفعالی (Proactive) رفتارکنیم.

مثال: برنامه‌ریزی

هنگامی‌که می‌خواهید رانندگی کنید تا به مقصد جدیدی بروید و زمان کمی هم دارید، می‌توانید فوراً راه بیافتید تا در زمان صرفه‌جویی کنید و با مشکلات احتمالی -هر زمان که پیش آمدند -دست‌وپنجه نرم کنید. رویکرد غیر انفعالی این است که در آغاز زمانی را برای تنظیم GPS اختصاص بدهید تا به شما سریع‌ترین مسیر را بر اساس وضعیت ترافیکی مسیر و تصادف‌های احتمالی و مسیرهای مسدود، نشان دهد و سپس شروع به رانندگی کنید. این زمان صرف شده قبل از حرکت به‌منظور پیشگیری از مشکلات آتی است بنابراین درنهایت در زمان صرفه‌جویی خواهیم کرد.

برخلاف آنچه برخی تصور می‌کنند برنامه‌ریزی همیشه برای پروژه‌های چابک (Agile) ضروری بوده و تفاوت تنها در نوع و سطح جزئیات موجود در برنامه است. برنامه‌ریزی قبل از اجرا رویکردی غیرانفعالی است.

این ضرب‌المثل را به یاد داشته باشید: اگر برای بریدن یک درخت شش ساعت به من زمان بدهید چهار ساعت از آن را برای تیز کردن تبر صرف خواهم کرد.

اگر پروژه شما متعین (Predictive) باشد شما احتمالاً چهار ساعت از وقتتان را برای تیز کردن تبر صرف می‌کنید چون مطمئن هستید که هدفتان قطع کردن درخت است. در پروژه‌های چابک (Agile) مطمئن نیستیم که هدف قطع کردن درخت است یا جمع‌آوری شاخه‌های شکسته، یا هرس کردن درخت، یا تهیه زغال یا چیز دیگر. به‌هرحال برای همه این اهداف نیاز به آماده‌سازی عمومی است (مثلاً بدانیم نزدیک‌ترین فروشگاه ابزارفروشی کجاست) و وقتی‌که می‌خواهید روی هدف خاصی تمرکز کنید، آماده‌سازی اختصاصی خواهیم داشت (تیز کردن تبر) این کار، برنامه‌ریزی است.

مثال: برنامه‌ریزیِ برنامه‌ریزی

برنامه‌ریزی روش اجرای پروژه یک رویکرد غیر انفعالی است. با برنامه ریزی روش تهیه برنامه ای که میخواهیم با آن پروژه را اجرا کنیم می‌توانیم (برنامه‌ریزیِ برنامه‌ریزی) غیرانفعالی بودنمان را توسعه دهیم. این مفهوم عبارت Management Plan در PMBOK® Guide و Management Strategies در PRINCE2® و approach های DSDM® است.

مثال: برنامه‌ریزی مداوم

بندرت آنچه در واقعیت اتفاق میافتد منطبق بر برنامه است و این طبیعی است اما باید دائماً برنامه‌هایمان را اصلاح کنیم تا اطمینان حاصل کنیم که برنامه‌هایمان کاربردی و واقع‌بینانه است. به‌محض اینکه نیاز به بازبینی و اصلاح احساس شد باید این کار انجام شود نه زمانی که به مشکل برخوردیم. این رویکرد غیرانفعالی است.

مثال: مدیریت ریسک

کل مفهوم مدیریت ریسک منطبق بر رویکرد غیر انفعالی است. وقتی‌که با وقایع غیرقطعی مواجه می‌شویم به‌جای آنکه منتظر بمانیم و ببینیم چه اتفاقی میافتد و بعد به آن واکنش نشان دهیم به احتمالات و اثراتشان فکر می‌کنیم، واکنش مناسب در برابر این رخداد ها را یافته و اگر لازم است که پیش از وقوع آن رخدادها کاری انجام بدهیم آن کارها را انجام میدهیم.

توجه داشته باشید آنچه در پروژه‌ها انجام می‌دهیم جدی است و بعضی وقت‌ها با زندگی افراد سروکار دارد.

مثال: تعریف نقش‌ها و مسئولیت‌ها

می‌توان اعضا تیم پروژه را بدون تعریف نقش و مسئولیت مشخص، رها کرد تا دیر یا زود نوعی نقش و مسئولیت برایشان پدیدار گردد این کار بسیار پرهزینه است و کارایی چندانی ندارد. در روش غیرانفعالی باید نقش‌ها و مسئولیت‌ها را در ابتدا تعریف کرد و در صورت لزوم افراد را برای آن مسئولیتها از قبل آماده کرد. این کار باعث می‌شود کار برای همه آسان‌تر شود و افراد به‌جای آنکه وقت خود را برای تصمیم‌گیری در خصوص تقسیم وظایف صرف کنند، روی انجام کارها تمرکز کنند.

تعداد و تنوع نقش‌ها بسته به نوع و ابعاد پروژه متفاوت است، می‌تواند تعریف ساده‌ای داشته باشد نظیر آنچه در Scrum آمده است و یا تعریف میانه‌ای مانند آنچه در یا تعریف جامعی نظیر آنچه در DSDM® و PRINCE2® آمده است. به‌هرحال فراموش نکنید که نقش‌های تعریف‌شده در این متدها فقط راجع به فعالیت‌های مدیریتی است و شما همواره نیاز به تعریف نقش‌هایی که جنبه فنی دارند خواهید داشت.

مثال: انتخاب‌های موجود

آیا باید پروژه را پیش از موعد مقرر خاتمه داد و یا باید آن را ادامه دهیم؟

بندرت پیش میاید که فقط دو گزینه پیشِ رو داشته باشیم حتی اگر از صورت‌مسئله اینگونه بنظر برسد. شما باید رویکرد غیرانفعالی داشته باشید و قبل از تصمیم‌گیری، تمام گزینه‌های ممکن را در نظر بگیرید. شاید بتوانید Scope پروژه را تغییر دهید، شاید بتوانید پروژه را متوقف کنید تا زمانیکه موضوع دیگری شفاف شود یا شاید بتوانید رویکرد پروژه را تغییر دهید (مثلاً برون‌سپاری) و …

مثال: تفکر انتقادی

همه ما تعصبات زیادی داریم که از یک‌سو کمک می‌کنند زنده بمانیم و از سوی دیگر باعث می‌شود تصمیمات نامناسبی بگیریم. وقتی نوبت به اتخاذ تصمیمات مهم در پروژه می‌رسد بهترین کار آن است که لحظه‌ای درنگ کرده و تمام تعصباتی را که می‌تواند روی تصمیماتمان اثر بگذارد را در نظر بگیریم پیش از آنکه مشکلی ایجاد کند.

به‌عنوان یک مرجع می‌توانید از لیست تعصبات شناختی در سایت ویکی‌پدیا به آدرس زیر استفاده کنید:

حتی چارچوب‌های (Frameworks) تصمیم‌گیری نیز وجود دارند تا به شما برای تصمیم‌گیری بهتر کمک کنند. در ابتدا ممکن است استفاده از این چارچوب‌ها، باعث پرت شدن حواس شما شود و یا حتی مزاحم شما باشد اما به‌سرعت به استفاده از آن عادت می‌کنید و حتی بدون تلاش‌های آگاهانه از مزایای آن برخوردار خواهید شد.

مثال: شفافیت

هیچ‌یک از ما دوست نداریم که در پروژه تأخیر افتاده یا مشکلی بوجود آید، اما بدین معنی نیست که باید این مسائل را پنهان کنیم. شما باید شفاف عمل کنید و ذینفعان پروژه را در جریان امور بگذارید، زیرا ممکن است آن‌ها بتوانند کمکتان کنند، از آن گذشته دیر یا زود آن‌ها متوجه آن مسئله و پیامدهای ناشی از آن خواهند شد در حالیکه ممکن است برخی از این مسائل نیاز به اقدام اولیه از سوی ایشان داشته باشد (مثلاً پذیرش عواقب منفی).

مثال: برقراری ارتباطات مؤثر

ممکن است خیلی وقت‌ها شما به ذینفعان پروژه گزارشی ارسال کنید و هیچ بازخوردی از آنان دریافت نکنید و تصور کنید که چون بازخورد منفی دریافت نکرده‌اید همه‌چیز روبه‌راه است در حالیکه ممکن است این‌گونه نباشد شما باید غیر امفعالی رفتار کرده و بررسی کنید که آیا واقعاً آن‌ها از آن گزارش استفاده کرده‌اند؟ آیا هدفی که از ارسال آن گزارش داشته‌اید محقق شده است؟ میبایست از این اطلاعات به‌عنوان ورودی برای تنظیم متد ارتباطی استفاده کنید در غیر این صورت این نکات پنهان می‌تواند باعث بروز مشکلات جدی در آینده شود که حل کردن آن‌ها به‌مراتب سخت‌تر خواهد بود.

مثال: مسئولیت‌پذیری

سرزنش کردن دیگران به دلیل کسب نتایج ضعیف کار آسانی است. مثلاً ممکن است شما از سازمانتان بخواهید که برای تغییر همه‌چیز در پروژه و اجرای بی‌عیب و نقص آن به شما اختیار تام بدهد اما سازمان این کار را نکند و درنتیجه پروژه با شکست مواجه شود این کار با رویکرد غیرانفعالی در تضاد است.

رویکرد غیرانفعالی آن است که شما مسئولیت‌پذیر باشید و باوجود همه محدودیت‌ها، تمامی آنچه در توان دارید را بکار بگیرید. شما نباید از سازمان انتظار داشته باشید که کاملاً به شما اعتماد کند و به امید کسب نتایج مثبت همه امکانات سازمان را در اختیار شما قرار دهد خصوصاً وقتی‌که آن‌ها پروژه‌های شکست‌خورده زیادی را دیده‌اند. کاری که شما باید انجام دهید این است که با همه آن محدودیت‌ها یک پیشرفت کوچک ایجاد کنید تا اندکی اعتماد ایشان را جلب کنید و بتوانید منابع بیشتری (هرچند اندک) برای تحمل محدودیت‌ها جذب کنید سپس از آن منابع برای ایجاد بهبود کمی بزرگ‌تر از قبل استفاده کنید و به این روند ادامه دهید تا زمانی که به هدف نهایی خود دست‌یابید.


استحکام یک زنجیر تنها به‌اندازه استحکام ضعیف‌ترین حلقه آن است

حوزه‌های مختلفی در پروژه وجود دارد که همگی آن‌ها باید موردتوجه قرار گیرند، ما باید چشم‌انداز جامعی از پروژه داشته باشیم. توجه به حوزه‌هایی که در نگاه اول مهم بنظر میرسند (مثل زمان) به‌تنهایی کافی نیست چون تمامی حوزه‌ها باهم در تعامل هستند و تا زمانی که به همه آن‌ها به میزان کافی توجه و رسیدگی نشود به‌درستی کار نخواهند کرد.

مثال: همه‌چیز با ضرب‌الاجل مرتبط است

فرض کنید که شما در حال ساختِ مکانی برای مسابقات المپیک هستید این کار دارای یک ضرب‌الاجل بسیار جدیِ زمانی است که اهمیت مدیریت زمان را دوچندان می‌کند. آیا موافقید؟

اگر کیفیت آن‌قدر کم باشد که پس از مدتی نیاز به دوباره‌کاری باشد چه؟ پس کیفیت میتواند روی زمان تاثیرگذار باشد. ممکن است در پروژه شما یک باغ فانتزی نیز تعریف شده باشد اما ذکر شده باشد که در صورت کمبود وقت می‌توان از آن چشم‌پوشی کرده و صرفاً آن زمین را چمن‌کاری کرد؛ بنابراین مدیریت محدوده کار (Scope Management) نیز مهم است. پس تا اینجا حوزه‌های زمان و کیفیت و Scope در کانون توجه ما قرار گرفت.

احتمالاً این داستان معروف را شنیده‌اید: زمانی که رئیس‌جمهور آمریکا، آقای کِنِدی از یکی از نگهبان‌های ناسا پرسید چه‌کار می‌کنی؟ او در پاسخ گفت “من اینجا برای فرستان انسان به کره ماه به دیگران کمک می‌کنم” آیا داشتن این‌گونه افراد در پروژه، به تحویل به‌موقع آن کمک نخواهد کرد؟

هر چه بیشتر پیش می‌روید متوجه خواهید شد که هر یک از این حوزه‌ها در مدیریت زمان مشارکت دارند و تازمانیکه شما به همه حوزه‌ها توجه نکنید نمی‌توانید ضرب‌الاجل‌ها را در سطح قابل قبولی از قطعیت برآورده کنید.

مثال: رفتار گزینشی

وقتی‌که افراد با متدهای متنوع مدیریت روبرو می‌شوند گاهی گزینشی رفتار کرده و هر آنچه از متدهای مختلف برایشان جذاب است را باهم ترکیب می‌کنند. این کار معمولاً بی‌نتیجه است زیرا اجزا به‌تنهایی کار نمی‌کنند، اجزایی که در کنار هم آورده میشود باید با یکدیگر سازگار باشند. هرگونه حذف، اضافه یا تغییر در یک سیستم باید با نگاهی جامع صورت پذیرد.

دلیل آنکه گاهی وقت‌ها اجزا ضد و نقیضی در متدهای مختلف می‌بینیم نیز همین است مثلا میبینیم که یک کار در یک متد خاص نتیجه می‌دهد و متضاد آن در متد دیگر. هر جزء، به‌خودی‌خود صحیح یا غلط نیست.

ایمن‌ترین رویکرد آن است که یک متدولوژی برای پروژه انتخاب کنید، آن را سفارشی‌سازی (Tailoring) کنید و پیوسته با در نظر گرفتن سازگاری آن با کل سیستم، اجزا دیگری به آن اضافه کنید.

مثال: رویکرد ضد فرآیند

یکی از بهترین مطالبی که در متدولوژی Agile آورده شده این است که توجه‌ها را به عوامل انسانی جلب کرده است. Agile Manifesto ارزش بیشتری برای اشخاص و تعاملاتشان در مقایسه با فرآیندها و ابزارها قائل است. اگرچه ممکن است که این مقایسه منصفانه‌ای نباشد. تقریباً تمام متدها به اهمیت عوامل انسانی اشاره می‌کنند و تفاوت واقعی آن‌ها با متد Agile آن است که عوامل انسانی به‌جای یک پیشنهاد ساده بخش مجزایی از فرآیندهای آن است. بحث پیرامون رقابت بین عوامل انسانی و فرآیندها نیست بلکه راجع به نحوه نگرش سیستمها به عوامل انسانی است.

شکی نیست که برخی از افراد سعی می‌کنند فرآیندهای پیشرفته‌تر را جایگزین عوامل انسانی کنند اما این تنها نوعی سوءِ رفتار است. حتی به‌طور مشابه افراد مخالف این ایده نیز وجود دارد و برخی در تلاش‌اند تا فرآیندها را با عوامل انسانی جایگزین کنند که این هم نتیجه خوبی نخواهد داشت.

مثال: تمام حوزه‌هایی که نیاز دارید اینجاست

وقتی به حوزه‌ها فکر می‌کنید باید مراقب باشید که هیچ‌کدام از آن‌ها را از قلم نیندازید. این حوزه‌ها کدم‌اند؟ اگر کتب مرجع را بررسی کنید جواب‌های متفاوتی خواهید یافت ، تا به امروز هیچ‌یک از آن‌ها کل حقیقت را بیان نکرده است.

تم‌های PRINCE2® همان حوزه‌ها هستند اما این تنها دامنه‌هایی است که نقش کلیدی در متدولوژی ایفا می‌کنند مابقی حوزه‌ها صرفاً به‌طور ضمنی اشاره‌شده.

PMBOK® Guide یک متدلوژی نیست و می‌توان آن را با 10 حوزه دانش (Knowledge Area) به‌طور مناسب‌تری فرموله کرد بااین‌حال، این حوزه‌های دانش تفسیری از تمام حوزه‌های پروژه مبتنی بر چشم‌انداز PMBOK® است . به‌عنوان‌مثال PMBOK® به عوامل انسانی توجه چندانی نمی‌کند.

ICB منبع مناسبی برای دریافت اطلاعات پیرامون حوزه‌هاست. اگرچه ICB راجع به حوزه‌ها نیست اما راجع به صلاحیت‌های موردنیاز در پروژه بوده و رابطه یک‌به‌یکی با حوزه‌ها ندارد اما برای شناسایی آن‌ها کمک شایانی می‌کند.

NUPP شامل لیست حوزه‌ها نمی‌شود در درجه اول به این دلیل که این‌یک متا سیستم است نه سیستم، ثانیاً به این دلیل که دسته‌بندی حوزه‌ها، به نوع پروژه و محیط آن وابسته است. به‌عنوان‌مثال یک پروژه ساخت‌وساز معمول ممکن است نسبت به یک پروژه تحقیقاتی ابتکاری چشم‌انداز متفاوتی نیاز داشته باشد.


بدون وجود هدف واضح و مشخص دست به انجام هیچ کاری نزنید

تا زمانیکه هدف روشنی از انجام کاری ندارید آن را انجام ندهید. دو جهان موازی را تصور کنید که در آن دو، همه‌چیز یکسان است به‌جز کاری که شما برای انجام، در نظر دارید. این دو جهان چقدر تفاوت خواهند داشت؟ آیا این تفاوت ارزش تلاش‌هایی که شما برای اجرای آن می‌کنید دارد یا نه؟

اگر هدف مشخصی در ذهن ندارید و کاری را صرفاً فقط به این دلیل انجام می‌دهید که بقیه نیز این کار را می‌کنند و اینکه دیگران میگویند انجامش مهم است:

  • ممکن است در رابطه با مساله شما واقعاً سودی نداشته باشد بنابراین چیزی نصیب شما نشود.
  • ممکن است برای شما مزایای بالقوه‌ای داشته باشد اما به دلیل آنکه هدفی در ذهنتان ندارید آن کار را به‌گونه‌ای انجام دهید که باعث شود به آن منافع نرسید.

مثال: پرتفولیو و طرح

اگر شما در انتخاب و راه‌اندازی پروژه‌ها دخیل هستید باید اطمینان حاصل کنید که بر روی منافع و مشکلاتی تمرکز کنید که از طریق اجرای آن پروژه قرار است برآورده شده یا حل گردند، نه بر روی محصولی که میتواند آن مشکل یا خواسته را برآورده کند. یک مثال کلاسیک: سازندگان آسانسورها، روزانه انتقادهای زیادی در خصوص سرعت آسانسورها دریافت می‌کردند پس پروژه‌های زیادی برای افزایش سرعت آسانسورها تعریف شد، اما موفقیتی به دست نیامد. این ماجرا ادامه پیدا کرد تا زمانی که آن‌ها تصمیم گرفتند به‌جای تمرکز بر روی راه‌حل‌های واضح (افزایش سرعت آسانسور) بر روی صورت مسئله تمرکز کنند (خستگی و یا ناراحتی مردم). نتیجه آن شد که در آسانسورها آیینه نصب کردند و مشکل، آسان و ارزان حل شد.

به یاد داشته باشید که مدیریت پروژه اساساً در رابطه با انجام صحیح کارها است در حالیکه مدیریت پرتفولیو با انجام کارهای صحیح مرتبط است. مهم نیست که چقدر خوب پروژه‌تان را انجام می‌دهید اگر شما پروژه غلطی را اجرا می‌کنید به نتیجه نخواهید رسید. همه‌چیز به هدفمندی شما برمی‌گردد.

مثال: کلیت پروژه

انعطاف‌پذیری محصولات در پروژه‌های مختلف، متفاوت است. در برخی پروژه‌های توسعه در صنعت IT، محصول کاملاً انعطاف‌پذیر است و شکل نهایی آن به بازخوردی که از توسعه تدریجی محصول (Increments) می‌گیریم وابسته است که نیازمند رویکرد تطبیقی (Adaptive approach in Agile) است. این عملیات ترکیبی از پرتفولیو، طرح و لایه‌هایی از پروژه است که نیازمند حداکثر توجه به هدف نهایی است. ایده خوبی است که هدف را مستند کرده و در دسترس قرار دهیم، این، یکی از اهداف “Product Vision” است که در برخی از پروژه‌های اسکرام استفاده می‌شود. توجه به ارزش کسب‌وکار (Business Value) در پروژه‌های Agile راهی برای تضمین هماهنگی باهدف است.

در دیگر مدل‌های پروژه که محصول آن‌ها نسبتاً ثابت است برای ارزیابی آنکه محصول شناسایی‌شده می‌تواند ما را به هدفمان برساند یا خیر مکانیسم‌های دیگری وجود دارد و برای اعضا تیم پروژه‌ این امکان وجود دارد که بخش عمده‌ای از تمرکزشان را به‌جای هدف به محصول معطوف کنند (اصل “Focus on Products” از PRINCE2®)، اما برای آنکه مطمئن شویم آنچه قرار است ساخته شود ما را به هدفمان می‌رساند همچنان یک توجه حداقلی به هدف موردنیاز است که از طریق مقایسه منافع پیش‌بینی‌شده با منافع کسب‌شده می‌توان به آن دست‌یافت. (اصل “Continued Business justification” و تم “Business Case” از PRINCE2®).

وقتی پروژه‌ای را برای کارفرمای خارج از سازمان انجام می‌دهید، کارفرما هدف خاص خود را از آن پروژه دارد و سازمان شما نیز هدف خاص خود را دارد که این اهداف لزوماً باهم یکسان نیستند. برای کامیابی واقعی در پروژه باید هر دو هدف را درک کرده و مدنظر قرارداد.

مثال: نظارت بر پروژه

تمرکز روی هدف نهایی لازم است، اما ممکن است این هدف برای بسیاری از استفاده‌های روزانه خیلی مختصر و کلی باشد به همین دلیل برای آنکه کاربردی‌تر باشد سلسله مراتبی از پیش برنده‌ها در پروژه موردنیاز است. توجیه مزایای پروژه در ابتدا بر مبنای هدف نهایی پروژه انجام می‌گردد سپس اهداف صریح و ضمنی را برای متغیرهای پروژه (مثل زمان، هزینه و کیفیت) تعریف می‌کنیم تا مزایای توجیه شده پروژه ارضا شود این کار به‌نوبه خود ما را به هدف نهایی می‌رساند. این اهداف جزئی تر برای انجام بسیاری از وظایف روزانه مفید خواهد بود.

وقتی نوبت به نظارت می‌رسد، نظارت جزئی در پروژه با استفاده از جزئی ‌ترین متغیرها انجام می‌گردد چون معمولاً پیگیری هدف نهایی به‌جز از طریق نظارت بر جزئیات امکان‌پذیر نیست. در این شرایط باید همچنان هدف را در ذهن داشته باشید. هدف از نظارت چیست؟

طبیعتاً یک پاسخ قابل‌قبول این است که می‌خواهیم ببینیم آیا در مسیر درست قرار داریم یا خیر؟ تا اگر در مسیر صحیح نیستیم واکنش مناسبی نشان دهیم که ما را به مسیر صحیح بازگرداند یا اهداف جزئی را اصلاح کنیم تا ببینیم آیا همچنان می‌توانیم به هدف نهایی‌مان برسیم یا خیر؟ بنابراین اهداف جزئی تر باید بتواند به ارزیابی‌های ما کمک کند و ارزیابی مناسب آن است که مقدار هر یک از متغیرهای ذکرشده در پایان پروژه را پیش‌بینی کند. مثلاً پروژه در چه زمانی قابل اتمام است؟ برای تکمیل پروژه چقدر پول لازم است؟

سایر ارزیابی‌ها نظیر مقادیر برنامه‌ریزی‌شده (Planned Values) و مقادیر واقعی تا به امروز (Actual Values) صرفاً مقادیر موقتی هستند که برای انجام پیش‌بینی‌ها نیاز دارید و مقادیر نهایی که برای اهداف مدیریتی استفاده می‌کنید نیستند.

مثال: اسناد

از هر یک از رویکردهای توسعه‌ای که در پروژه‌تان استفاده کنید، همیشه برنامه‌ریزی امری ضروری است. مساله اساسی، سطح جزئیات موجود برنامه است. اگر جزئیات کافی در برنامه وجود نداشته باشد برنامه نمی‌تواند به میزان کافی سودمند باشد و اجرای پروژه بیش از آنکه برمبنای تصمیمات یکپارچه و جامع باشد بر مبنای تصمیمات موردی خواهد بود. از طرف دیگر بسیاری افراد تلاش می‌کنند محتاط باشند و جزئیات بیشتری به برنامه‌شان اضافه کنند که تهیه و نگهداری برنامه را بسیار سخت کرده و در برابر عدم قطعیت‌های پروژه خشک و غیرقابل انعطاف می‌کند، درنتیجه برنامه غیرواقعی و بی استفاده می‌گردد.

بهترین راه برای تصمیم‌گیری در خصوص میزان جزئیاتِ لازم، آن است که برای تمامی اجزا برنامه هدفی در ذهن داشته باشید. مثلاً اگر می‌خواهید منابع را به برنامه‌تان اضافه کنید باید هدفی از انجام این کار داشته باشید و بدانید که چگونه قرار است از آن استفاده کنید؟ چگونه قرار است به پروژه کمک کند؟ چه مقدار تلاش و انرژی خواهد برد؟ و آیا ارزشش را دارد یا خیر؟

گاهی اوقات مساله تصمیم‌گیری در خصوصِ لحاظ کردن عنصری خاص در برنامه‌هاست و گاهی در خصوص روش برنامه‌ریزی و یا تهیه چیزی است. چه Business Case باشد، چه Project charter و یا یک گزارش، شما باید همواره از خودتان بپرسید که هدف از تهیه این مدرک یا سند چیست و چگونه به پروژه کمک خواهد کرد.

به دنبال یک الگو (Template) بودن، با انجام کار بر مبنای هدف مشخص در تضاد است.

مثال: گزارش وضعیت

وجود گزارش‌های عریض و طویل در پروژه‌ها شایع است. طبق این NUP، می‌بایست از خودمان بپرسیم که هدف از تهیه یک گزارش چیست و چگونه می‌توانیم به آن هدف برسیم صرف‌نظر از اینکه دیگران اغلب چه می‌کنند.

داشتن هدف اغلب اوقات منجر به تولید گزارش‌های بسیار ساده یک‌صفحه‌ای می‌شود که ذینفعان واقعاً آن را مطالعه می‌کنند و نسبت به گزارش‌های طولانی قابل‌فهم‌تر است. این نتیجه توجه به هدف است.

وقتی گزارش‌های یک‌صفحه‌ای تهیه می‌کنید ممکن است برای برخی سو تفاهم پیش بیاید و فکر کنند که سیستم نظارتی مناسبی ندارید. عملاً این کار هدف ثانویه‌ای را نیز به دنبال دارد (در کنار هدف اولیه که کمک به فهم وضعیت پروژه برای ذینفعان است) هدف ثانویه این است که در صورت لزوم بتوانید گزارشات مفصلی را برمبنای آن گزارش یک صفحه ای تهیه کنید. به‌هرحال نباید این هدف را باهدفِ تهیه گزارش اولیه ادغام کرد زیرا هدف از تهیه این دو یکسان نیست.

مثال: Business Case و Project charter

تهیه مدارکی نظیر Business Case و Project charter برای اکثر مردم معمولاً خسته‌کننده، بی‌فایده است، که صرفاً به دلیل ضرورت‌های بوروکراتیک تهیه می‌گردد در صورتیکه این مدارک همگی دارای اهداف معتبری هستند که در اکثر پروژه‌ها اعمال می‌شود. اگر شما به دنبال یافتن یک الگو هستید تا آن را پرکنید این کار بیهوده است، در حالیکه شما می‌توانید به‌جای آن، هدف واقعی از تهیه این‌گونه مدارک را دنبال کنید، ببینید این مدارک می‌تواند به پروژه شما کمک کند یا خیر؟ و چگونه؟ بعد با هر روشی که دوست دارید مدارک را تهیه کنید تا به هدف موردنظر برسید. در اینصورت خروجیِ آن، مدرک مناسبی خواهد بود.

وقتی به روش تهیه این اسناد برای تأمین اهداف موردنظر می‌اندیشید احتمالاً به تمام سناریوهای ممکن فکر نکرده و برخی از آن‌ها را از قلم خواهید انداخت، به‌منظور پیشگیری از وقوع چنین اتفاقی، می‌توانید بررسی کنید که منابعی نظیر PRINCE2®, PMBOK® Guide, و DSDM® چه پیشنهادی می‌دهند، سپس پیشنهادها را بر مبنای اهداف خودارزیابی کنید.

مثال: پسا پروژه

ازآنجاکه پروژه هدف مشخصی دارد، می‌توانیم آن هدف را در سرتاسر پروژه لحاظ کنیم، تحقق هدف اصولاً با پیش‌بینی‌های انجام‌شده در طول پروژه ارزیابی می‌شود. حتی زمانی که پروژه به اتمام می‌رسد نباید هدف را فراموش کنیم. به دلایل زیر مهم است که پس از اتمام پروژه، تحقق اهداف را بررسی کنیم:

  • می‌توانیم بفهمیم که اهداف نهایی چگونه محقق شدند و برای پروژه‌های آینده از آن یادگیری داشته باشیم.
  • گاهی، اهداف زمانی محقق می‌شوند که پس از اتمام پروژه چند فعالیت اضافی انجام شود و درک لزوم انجام این فعالیت‌ها نیاز به نظارت دارد.

نظارت پسا پروژه یک گام ضروری برای هدف محور بودن است. اساساً مسئولیت این کار، بر عهده سیستمهای مدیریت پرتفولیو و مدیریت طرح است اما ازآنجاکه بسیاری از شرکت‌ها این‌گونه لایه‌های مدیریتی را در خود ندارند این گام‌ها معمولاً مورد غفلت واقع می‌شوند. به این دلیل است که متدهایی نظیر و DSDM® این گام را به متدولوژی‌های مدیریت پروژه خود اضافه می‌کنند.

مثال: سادگی

دنیا پیچیده و بی‌نظم است، اما مدل‌های ما تقریباً انتزاعی بوده و بخشی از این دنیا را منعکس می‌کنند تا برای ما ساده تر شود. از سوی دیگر، سیستمهای ساده معمولاً بهتر کار می‌کنند، چون می‌توانیم روی ایده اصلی بهتر متمرکز شویم.

بسیاری از ما سعی می‌کنیم تا برای دستیابی به نتایج بهتر به سیستمهایمان پیچیدگی اضافه کنیم با این ذهنیت که این کار باعث می‌شود بر پیچیدگی‌های دنیا منطبق شویم اما در عمل باعث می‌شود که کار با سیستمها سخت‌تر شده و مانع دستیابی به اهدافمان شود.

مثال: سفارشی‌سازی

شرایط یک نرم‌افزار ساخت و ویرایش موسیقی نسبت به نرم‌افزاری که برای تجهیز بیمارستان و یا هواپیما تهیه می‌شود که با جانِ افراد سروکار دارد یا نرم‌افزار تهیه شده برای استفاده در ماهواره‌هایی که قرار است سال‌های سال بدون مشکل کار کند متفاوت است و همه آن‌ها با ساخت یک ویلای تابستانی، ایستگاه آتش‌نشانی یا یک کارخانه تفاوت دارند.

وقتی هدفی در ذهن داشته باشید درک بهتری از نحوه سفارشی‌سازی سیستمها و مصنوعات (Artifacts) برای پروژه‌های مختلف دارید.


از اجزا تکرار پذیر استفاده کنید

رویکرد تصمیم گیری موردی در پروژه انرژی بر بوده و منابع زیادی برای آن صرف می‌شود و همیشه ریسک از قلم افتادن برخی از اجزا را به همراه دارد. بهترین راه برای ساده‌سازی آنچه قرار است انجام شود آن است که از اجزا تکرارپذیر استفاده گردد و ترجیحاً آن‌ها را در چرخه‌های قابل تکرار قرار داد.

مثال: چک‌لیست‌های کیفی

چک‌لیست یک نمونه ساده از اجزایی است که پتانسیل تکرارپذیری را دارد که خیلی از افراد در زندگی شخصی و کاری خود از آن استفاده می‌کنند، به‌عنوان‌مثال:

  • در ابتدای پروژه در وهله اول احتمالاً چک‌لیستی از تمامی معیارهای لازم تهیه می‌کنید که این، یکی از انواع برنامه‌ریزی است.
  • آنچه NUP 6 توصیه می‌کند این است که “تعمیم دهید”. بررسی کنید که آیا اقلام تحویل شدنی (Deliverable) مشابهی در پروژه وجود دارد؟ در صورت وجود، یک چک‌لیست برای کیفیت آن دسته از اقلام تهیه کنید و از آن برای همه اقلام تحویل شدنی استفاده کنید. اگر اختلافاتی وجود دارد، لیست عمومی را حفظ کنید و چند مورد اضافی برای آن تحویل شدنی خاص به آن بیفزایید. تا به یک چک‌لیست‌ تکرارپذیر برسید.
  • زمانی که شما چک‌لیست‌های عمومی را برای انواع مختلف اقلام تحویل شدنی تهیه می‌کنید ممکن است با اجزایی برخورد کنید که زیرِ آن‌ها تکرار می‌شوند در این شرایط بجای تکرار آیتم‌ها برای تمامی چک‌لیست‌های عمومی، می‌توانید آن‌ها را بیرون کشیده و به چک‌لیست‌های عمومی اضافه کنید. درنهایت احتمالاً یک چک‌لیست عمومی منحصربه‌فرد برای کل پروژه خواهید داشت. “Definition of done” در اسکرام یک مثال برای استفاده از چک‌لیست‌های کیفی در سطح پروژه است. با این کار هر تحویل شدنی، متعلق به یک سلسله‌مراتب از دسته‌بندی‌ها خواهد بود و می‌بایست الزامات موجود در چک‌لیست‌های متعلق به دسته‌بندی‌های زنجیره خود را رعایت کند.

به این ترتیب آیتم‌های موجود در چک‌لیست مادر، برای تمامی تحویل شدنیهای زیرمجموعه آن تکرارپذیر می‌شوند که باعث صرفه‌جویی در زمان و انرژی حین برنامه‌ریزی و اجرا خواهد شد.

مهم‌تر آنکه، وقتی شما این کار را برای یک پروژه انجام دهید می‌توانید آن را سفارشی‌سازی کرده و برای پروژه‌های مشابه در آینده نیز استفاده کنید.

مثال: فرآیندها و گردش کارها

برخی از اقلام تحویل شدنی یا هدف‌های مرتبط با آن به گام‌های مشخصی احتیاج دارند که می‌توان آن گام‌ها را استاندارد و تکرارپذیر کرد. به‌عنوان‌مثال اگر اقلام تحویل شدنی نیاز به طراحی و تائید اختصاصی داشته باشند بمنظور پیشگیری از بروز مشکلات احتمالی، می‌توان یک گردشِ کار ساده برای آن تهیه کرد که همه گام‌های لازم، افرادِ درگیر و زمان‌های تقریبی را شفاف بیان کند. مراقب باشید که گردشِ کارها و فرآیندها را بیش‌ازحد پیچیده نکنید چون تبعات منفی خواهد داشت. همه افراد درگیر در پروژه باید گردش-کارها و فرآیندها را به‌عنوان یک پشتیبانِ کاری و تسهیل‌کننده بدانند نه یک بروکراسی اداری که مانع کارشان است.

پروژه‌های Agile ، اجزا تکرارپذیر دارد که در رویکرد توسعه گام‌به‌گام (Iterative Development Approach) فعالیت‌های توسعه‌ای مشخصی برای هر قابلیت (Feature) تکرار می‌شود. مثلاً روال معمول روزانه در XP(eXtreme Programming) عبارتند از: جفت کردن، انتخاب یک آیتم، طراحی آن بر روی تخته وایت برد، ساخت اسکریپتها و کدهای آزمایشی و یکپارچه‌سازی کدها و …

در کنار گردش کارهای تکرارپذیر که می‌تواند برای فعالیت‌های فنی استفاده شود، شما می‌توانید برای فعالیت‌های مدیریت پروژه نیز فعالیت‌های تکرارپذیر داشته باشید. فرآیندها در PMBOK® Guide، PRINCE2® و DSDM®، فعالیت‌ها در و رویدادها در Scrum مثال‌هایی از این مفهوم هستند.

مثال: چرخه‌ها

داشتن اجزا تکرارپذیر در مدیریت پروژه مفید است. با قرار دادن این اجزا در چرخه‌های تکرارپذیر می‌توان باز هم آن ها را ساده‌تر کرد. این چرخه‌ها به میزان قابل‌توجهی فعالیت‌های روزمره افرادِ درگیر در مدیریت و رهبری پروژه را تسهیل می‌کند. چرخه ی Process group های PMBOK® Guide وقتی در پروژه‌ای با فازها و مراحل چندگانه استفاده میشود Stage ها در PRINCE2®، چرخه‌های روزانه و هفتگی و ماهیانه در، تکرارها و Timebox ها در DSDM® و اسپرینت‌ها در اسکرام همگی مثال‌هایی از این مفهوم هستند.

چرخه‌های کوتاه‌تر قابل‌فهم‌تر و قابل‌استفاده‌تر از چرخه‌های طولانی‌مدت هستند. مثلاً اسپرینت ها در اسکرام در مقایسه با فازهای پروژه در PMBOK® Guide. بااین‌حال چرخه‌هایی که خیلی کوتاه‌اند ممکن است برای پشتیبانی از برخی از پروژه‌ها مناسب نباشد و راه‌حل آن می‌تواند استفاده مکرر از چرخه‌ها باشد مثلاً استفاده از چرخه‌های کوتاه Timebox همراه با چرخه‌های تکرار طولانی‌تر در DSDM®، یا استفاده از چرخه‌های روزانه و هفتگی و ماهیانه در

مثال: متدها

استفاده از متدلوژی‌ها و چارچوب‌ها برای اجرای پروژه‌ها کاربرد دیگری از اجزا تکرارپذیر است خواه یکی از سیستمهای موجود نظیر PRINCE2®، DSDM®، یا Scrum باشد یا سیستمی که شما برای خودتان ساخته یا سفارشی‌سازی کرده‌اید، اگرچه معمولاً بهتر است به جای آنکه متدی را از ابتدا بسازید، با یکی از متدهای موجود کارتان را شروع کنید و آن را با نیازهایتان وفق دهید.

همه اجزا تکرارپذیر خلاصه بوده و نیاز به سفارشی‌سازی و تطبیقِ آن با دنیای واقعی دارید؛ طیفی از مفاهیم و نیازها برای سفارشی‌سازی وجود دارد، چک‌لیست‌های کوچک و نسبتاً خشک در یک سمت این طیف با کمترین میزان انتزاع و نیاز به سفارشی‌سازی و متدولوژی‌ها با بیشترین میزانِ نیاز به سفارشی‌سازی در سمت دیگر این طیف قرار دارند. همواره باید نیاز به سفارشی‌سازی موردتوجه قرار گیرد در غیر این صورت اجزا تکرارپذیر به‌خوبی پاسخگوی نیازتان نخواهد بود.


NUPP (Nearly Universal Principles of Projects) è un insieme di principi generali da seguire in tutti i progetti, indipendentemente dalle metodologie e dagli approcci utilizzati per massimizzarne il successo.

Qualsiasi metodo o risorsa usata per l’esecuzione di progetti presta attenzione a qualcuno di questi principi NUP (Nearly Universal Principles), tuttavia:

  • di solito non tutti, mentre sarebbe utile per i professionisti considerare tutti i NUP al posto di un loro sottoinsieme, inoltre
  • i principi di base spesso non sono abbastanza dettagliati riguardo le risorse, così la maggior parte dei professionisti si impegnano in dettagli pratici e tralasciano tali principi.

NUPP è compatibile con tutti i principali metodi, sistemi, risorse e framework, come PRINCE2®, PMBOK® Guide,, PM², DSDM®, XP e Scrum. Siccome potrebbe essere considerato non compatibile con alcune interpretazioni di questi sistemi, NUPP cerca di incoraggiare i professionisti a riconsiderarle.

Di seguito l’elenco dei NUP:


Preferisci i risultati e la verità rispetto agli schieramenti

Abbiamo tutti una naturale tendenza ad appartenere a dei gruppi che spesso va oltre la sua forma generale, creando forti schieramenti e causando problemi. Così perdiamo molto più di quello che guadagniamo. Possiamo diventare esperti più professionali ed efficaci se non limitiamo la nostra identità e le nostre preferenze in funzione solo dell’appartenenza a determinati gruppi.

Esempio: Agile vs. waterfall

Quando nei progetti di sviluppo software la regola era di usare approcci “predittivi”, un gruppo di persone molto determinate ha avuto il coraggio di provare approcci di sviluppo “adattivi”, si è riunito e ha definito questa modalità “Agile”. E’ stata una grande iniziativa per non limitare le scelte a ciò che sembrava scontato. Tuttavia, così come ci sono molte persone entusiaste e concrete, sfortunatamente nella comunità Agile ci sono anche alcune persone che trasformano Agile in una setta e considerano gli estranei come nemici. Questo causa diversi problemi:

Non consente loro di imparare da qualcuno al di fuori del “gruppo”

Scoraggia gli estranei al gruppo ad apprendere da loro.

Rende l’appartenenza al gruppo più importante del vero scopo, cosa che a sua volta impedisce a molti dei loro membri di imparare il vero significato di Agilità.

Questo problema può essere ridotto in modo significativo, se non addirittura rimosso, considerando Agile solo come un approccio di sviluppo, piuttosto che una comunità con persone che si considerano creatori, risolutori di problemi e leader. Per tutti costoro Agile dovrebbe essere solo un fattore abilitante, non la loro identità. Non c’è una guerra tra Agile e Waterfall per un vero professionista.

Esempio: PRINCE2® vs. PMBOK® Guide

Nella comunità di professionisti molti hanno come riferimento il PRINCE2® o la Guida PMBOK®, di solito per motivi di collocazione geografica o scelta aziendale. Ne conoscono uno, senza conoscere l’altro. Possiamo certamente avere delle preferenze nei riguardi di specifici riferimenti, ma non come elemento distintivo della nostra identità e, ancor più, dovremmo familiarizzare con entrambi per ampliare le nostre prospettive e le nostre scelte. Un vero professionista è aperto a tutte le idee, cercando di conoscerle, apprenderle e utilizzarle in base al bisogno che se ne delinea, senza schierarsi esclusivamente con nessuna di esse.

Esempio: apprendimento continuo

Lo schieramento soddisfa le persone attraverso il senso di appartenenza, non stimola l’apprendimento di cose nuove e lo scoraggia per paura di perdere i propri punti di riferimento. Se sei una persona libera, un esperto che non si annulla in un’idea specifica, hai bisogno di colmare lacune, attraverso l’apprendimento. Un apprendimento continuo.

Ciò in cui crediamo oggi non è la verità assoluta. E’ solo la migliore comprensione che abbiamo maturato sino ad ora, che deve essere migliorata man mano che procediamo. C’è qualcosa di sbagliato se le idee di qualcuno sono esattamente le stesse ad alcuni anni di distanza. Questo è anche il caso di NUPP: se dovessi tornare ad interessartene dopo qualche anno e trovassi esattamente le stesse cose, dovresti insospettirti.

Esempio: apertura mentale

Quando ti opponi a qualcuno, assicurati di obiettare l’idea, non la persona. Questo aiuta a prevenire molte tensioni. D’altra parte, se qualcuno ti critica, cerca di non interpretare questo come una guerra nei tuoi confronti, ma come una discussione sulla tua idea e rimani aperto al confronto. Non ascoltare per rispondere, ascolta per comprendere e lavora con l’altra persona per migliorare l’idea. Tuttavia, alcune persone potrebbero intenzionalmente scegliere come obiettivo te, invece della tua idea. In tal caso, aiutali a concentrarsi sull’idea - anziché su di te - prima di procedere e cerca di mantenerti così durante tutta la conversazione.


Preserva e ottimizza energia e risorse

Le risorse sono limitate. Le risorse disponibili per un progetto sono limitate, così come le energie mentali a tua disposizione per prendere buone decisioni. Dovresti usarle con parsimonia e ottimizzare queste risorse per te stesso e il progetto, nonché aiutare i membri del team a fare lo stesso.

Esempio: la regola 80/20

Una gran parte dei possibili benefici della gestione di un progetto viene conseguita con poco sforzo. Nella maggior parte dei casi, assicurarsi il 100% dei possibili benefici è troppo costoso e non giustificabile. Devi considerare questa regola in tutto ciò che fai, incoraggiando gli altri a fare lo stesso.

Esempio: stanchezza decisionale

Usiamo un’unica fonte di energia mentale per prendere ogni tipo di decisione ed esprimere la nostra forza di volontà. Se si utilizza troppa energia per decisioni non necessarie, o non importanti, ne avremo di meno per quelle importanti e potremmo ottenere risultati scadenti. Questo è uno dei motivi per cui dovresti evitare la micro-gestione (o micro management, secondo il principio di “gestione per eccezione” di PRINCE2®).

I conflitti che riguardano le idee possono essere utili, ma quelli che riguardano le persone sono di solito dannosi per il progetto e una delle conseguenze di ciò è prosciugare l’energia mentale dei membri del team. Se vedi un tale conflitto, dovresti fare del tuo meglio per trovare la causa alla radice e risolverlo.

Esempio: prenditi cura di te stesso!

Le decisioni che prendi e la forza di volontà che esprimi usano la tua fonte di energia mentale. D’altra parte, questa fonte è abbondante quando dormi e mangi correttamente. Quindi, abbi cura di te stesso: assicurati di dormire a sufficienza, riposati e mangia bene. Se hai abitudini o problemi che danneggiano il tuo sonno, non devi occupartene da solo; ci sono molti specialisti che possono aiutarti a risolvere il problema più facilmente. Può esserti di aiuto anche l’attività fisica, ma gli studi non hanno ancora detto una parola definitiva.

Cerca allora di incoraggiare i membri del team a fare la stessa cosa. In primo luogo, assicurati che lavorino con un ritmo sostenibile e senza eccedere con l’impegno sul lavoro. Quindi, se hai la possibilità, prova a offrire cibo, snack e bevande energetiche e sane durante il lavoro.

Esempio: equilibrio vita-lavoro

Molti di noi amano ciò che fanno, ma non è tutto quello che dobbiamo avere nella vita. Così come ottimizzi il tuo lavoro, dovresti pianificare e realizzare i progetti della tua vita personale, in modo da renderla gioiosa e felice. Quando sei più felice, puoi avere più successo anche sul lavoro. Se puoi, prova a incoraggiare i membri del tuo team a fare lo stesso.

Esempio: motivazione

La motivazione è un concetto complesso. Ci sono alcuni riferimenti interessanti e utili sull’argomento e, ancora, molti non scientifici. Tuttavia, dovresti leggere e apprendere elementi sulla motivazione e usarli continuamente, poiché aumenta l’energia mentale della squadra e la possibilità di ottenere risultati migliori nel progetto. Stimolare la motivazione può essere semplice come far sapere alle persone che hai riconosciuto il loro buon lavoro con un sorriso gentile, o un semplice “grazie”. Tuttavia, fai attenzione perché molti dei modi comuni per motivare hanno un effetto negativo, come ad esempio usare esclusivamente le ricompense monetarie.

Esempio: collaborazione e lavoro di squadra

Le persone che collaborano veramente creano risultati migliori, ma soprattutto va tenuto presente che gli esseri umani sono socievoli e sono felici di far parte di un gruppo. Se è possibile rimuovere gli aspetti negativi del lavoro di squadra e creare un ambiente piacevole, ci saranno membri del team più motivati nel progetto. Bisogna tuttavia fare attenzione alle diversità tra gli individui: alcuni hanno bisogno di maggiore calma, di concentrazione e solitudine rispetto ad altri; in generale occorre equilibrio.

Esempio: cultura “one-team”

C’è una tendenza generale, da parte dei diversi membri coinvolti in un progetto, a creare o a considerare sottogruppi, che non mancano di creare tensione con altri gruppi. Ad esempio, tra persone che si concentrano sugli aspetti commerciali del progetto e le persone che stanno producendo il prodotto. Questa tensione consuma molta energia da entrambe le parti, e questo è uno dei motivi per cui dovremmo provare a costruire una cultura di squadra, dove tutti lavorano insieme con un unico obiettivo.

Esempio: la saggezza collettiva

Quando un gran numero di persone con diversità e differenze si riuniscono e lavorano in un ambiente facilitato, si sviluppa il potenziale per ottenere ottimi risultati, idee e soluzioni, che potrebbero essere anche migliori di quelle provenienti da singoli esperti.

Se ne hai la possibilità, chiedi regolarmente ai membri del team di aiutarti a risolvere problemi difficili nel progetto. Oltre alla possibilità di ottenere buoni risultati, ciò permette anche ai membri del team di sapere che le loro opinioni sono apprezzate e che svolgono un ruolo importante nel progetto; il che, a sua volta, aumenta il loro livello di energia. L’attività # 26 di è un esempio dell’uso della saggezza collettiva nei progetti.

Esempio: capo facilitatore del progetto

Se sei un project manager, la maggior parte delle cose che fai hanno come obiettivo la facilitazione (o almeno dovrebbero averla). D’altra parte, dovresti riconoscere quali membri del team hanno avuto precedenti brutte esperienze con i project manager, tali esperienze hanno un impatto sul rapporto con te: ne deriva che, invece di fidarsi di te, una parte della loro energia viene spesa per analizzare il tuo comportamento in vista di potenziali minacce. In questi casi potresti modificare il titolo da “project manager” a “Chief Project Facilitator”. Dopotutto, questo è ciò che realmente fai nel progetto.


Sii sempre proattivo

In noi c’è una naturale tendenza ad essere reattivi. Questo può aiutarci a preservare le nostre energie evitando di spenderle in questioni non importanti, o potrebbe darci risultati migliori quando abbiamo a che fare con qualcosa in cui siamo completamente incompetenti. Queste situazioni sono diverse dai nostri progetti, dove invece otteniamo risultati migliori essendo proattivi.

Esempio: pianificazione

Se vuoi guidare un’automobile verso una nuova destinazione e sei in ritardo, è possibile iniziare immediatamente a guidare per “risparmiare tempo” e affrontare eventuali problemi quando si presentano. L’approccio proattivo consiste nel prendersi un po’ di anticipo per impostare il navigatore in modo da darti il percorso più veloce, in base al traffico e ai possibili incidenti e code, e solo successivamente cominciare a guidare. Passerà del tempo prima dell’esecuzione, ma eviterai problemi e alla fine risparmierai tempo.

Al contrario di quello che qualcuno pensa dei progetti Agili, la pianificazione è sempre necessaria, e la differenza riguarda solo il tipo e il livello di precisione dei piani. Pianificare prima dell’esecuzione è un approccio proattivo.

Ricorda la citazione: “dammi sei ore per abbattere un albero e userò le prime quattro ore per affilare l’ascia”.

Se si tratta di un progetto predittivo, puoi spendere quattro ore per affilare l’ascia, perché sei sicuro di abbattere un albero. In un progetto Agile, non sei sicuro se abbattere un albero, raccogliere rami spezzati, raccogliere erba, carbone o altro. Tuttavia, è ancora necessario avere una preparazione generale per tutti questi aspetti (sapere dove si trova il negozio di ferramenta più vicino) e avere una preparazione specifica (affilatura) quando ci si concentrerà su una determinata soluzione; questa è pianificazione.

Esempio: pianificare la pianificazione

Pianificare il modo in cui eseguiremo il progetto è un approccio proattivo. Questa proattività può essere estesa anche pianificando il modo in cui pianificheremo l’esecuzione; questo è il concetto del piano di gestione della guida PMBOK®, le strategie di gestione di PRINCE2® e gli approcci in DSDM®.

Esempio: pianificazione continua

La realtà raramente si presenterà perfettamente come abbiamo pianificato, e questo è accettabile. Dobbiamo adattare continuamente i nostri piani per assicurarci che restino realistici e pratici. Dovremmo farlo non appena l’adattamento è necessario, non quando ci imbattiamo in problemi; questo è un approccio proattivo.

Esempio: gestione dei rischi

L’intero concetto di gestione del rischio si basa sulla proattività: quando si affrontano eventi incerti, invece di aspettare di vedere cosa succede e poi reagire, pensiamo alle probabilità e agli impatti, prendiamo in considerazione alcune azioni e - possibilmente - facciamo qualcosa al riguardo prima che accada.

Considera che ciò che facciamo nei progetti è importante e impattante; a volte riguarda le vite delle persone stesse.

Esempio: definire ruoli e responsabilità

Puoi lasciare che i membri del team di progetto lavorino senza ruoli e responsabilità chiare, confidando che prima o poi emergeranno autonomamente in una certa forma, ma è troppo costoso e dopotutto potrebbe non funzionare bene. L’approccio proattivo è definire ruoli e responsabilità in anticipo e adattarli secondo necessità. Ciò rende il lavoro più facile per tutti, permettendo di concentrarsi sulla realizzazione pratica, invece di interrogarsi su chi fa cosa.

Il numero e la varietà dei ruoli dipendono dal tipo e dalla dimensione del progetto; può essere una definizione semplice come quella di Scrum, qualcosa di moderato come quello di, o qualcosa di completo come quelli in DSDM® e PRINCE2®. Tuttavia, non dimenticare che la descrizione dei ruoli in questi metodi riguardano solo le attività di gestione e che quindi devi sempre aggiungere la descrizione relativa ai ruoli tecnici.

Esempio: scelte disponibili

Devi chiudere il progetto prematuramente o continuarlo?

Raramente ci sono solo due scelte, anche se la domanda lo sottintende. Devi avere un approccio proattivo e prendere in considerazione tutte le opzioni prima di prendere una decisione. Forse puoi salvare il progetto; forse puoi metterlo in pausa fino a quando la situazione diventa chiara; forse puoi cambiare l’approccio al progetto (ad esempio, l’outsourcing), ecc.

Esempio: pensiero critico

Abbiamo tutti molti pregiudizi, che da una parte ci aiutano a sopravvivere e dall’altra ci ingannano facendoci prendere decisioni sbagliate. Quando si tratta di prendere decisioni importanti nel progetto, è meglio fermarsi e considerare tutti i pregiudizi che possono avere un impatto sulla nostra decisione, prima che causino un problema.

Come riferimento, puoi usare la lista dei “bias cognitivi” disponibile su Wikipedia:

Esistono persino modelli e quadri decisionali che è possibile utilizzare per prendere decisioni migliori. All’inizio può essere fonte di distrazione e persino fastidioso usarli, ma presto ci si abitua e se ne puoi trarre profitto senza troppo sforzo.

Esempio: trasparenza

Non ci piace essere in ritardo nel progetto o avere altri problemi, ma ciò non significa che dovremmo nasconderlo. Sii trasparente e fallo sapere agli stakeholder, perché alcuni di loro potrebbero essere in grado di aiutarti. Prima o poi anche loro verranno a conoscenza dei problemi e relative implicazioni e alcuni Stakeholder potrebbero dover intraprendere azioni tempestive (ad esempio, accettare conseguenze negative).

Esempio: comunicare efficacemente

Possono esserci molti casi in cui si inviano relazioni a varie parti interessate al progetto, senza poi ottenere alcun feedback. Potresti credere che tutto vada bene solo perché non ci sono feedback negativi, anche se potrebbe non essere così. Devi essere proattivo e controllare se hanno realmente ricevuto e compreso le comunicazioni e i report, se hanno raggiunto lo scopo, utilizzando il feedback come input per aggiustare la tua comunicazione. Altrimenti questo problema nascosto potrà causare seri problemi in seguito, quando sarà troppo difficile o troppo tardi per risolverlo.

Esempio: assumersi le responsabilità

E’ facile accusare gli altri dei risultati scadenti. Per esempio, cerchi di ottenere il pieno potere di cambiare tutto nel progetto, ma non te lo concedono e quindi il progetto fallisce. Questo non è un atteggiamento proattivo.

L’approccio proattivo è assumersi la responsabilità e fare tutto il possibile entro i limiti. Non puoi aspettarti che l’organizzazione si fidi di te e ti dia tutto con la speranza di ottenere buoni risultati, specialmente quando in passato hanno visto fallire tanti progetti. Quello che devi fare è fare un piccolo miglioramento entro i limiti impostati, usarlo per guadagnare fiducia, un po’ più di risorse e un po’ più di tolleranza ai vincoli, usando questi vantaggi per ottenere un ulteriore miglioramento leggermente più grande, e procedere così fino a raggiungere un risultato ottimale.


Ricorda che una catena è forte quanto il suo anello più debole

Ci sono vari domini nei progetti, e tutti hanno bisogno di attenzione; dobbiamo avere una prospettiva olistica per il progetto. Prestare attenzione a un dominio apparentemente importante (ad esempio, il tempo) non è sufficiente, perché tutti i domini interagiscono e non funzionano correttamente a meno che tutti ricevano sufficiente attenzione.

Esempio: è tutta questione di scadenze!

Immagina una situazione in cui stai costruendo qualcosa per i giochi olimpici. Hai una scadenza improrogabile che rende la gestione del tempo molto importante. Sei d’accordo?

Che cosa succede se la qualità è così bassa da causarne la rilavorazione? Questo avrà un impatto sul tempo. Questo evidenzia che la qualità è correlata al tempo. Potresti avere un giardino elegante nella definizione originale del progetto ma, se non ci fosse abbastanza tempo, potresti stralciarlo o cambiarlo seminando semplicemente l’erba, purché tu abbia considerato questa possibilità e ti sia preparato a questa eventualità. Quindi, anche la gestione dell’ambito è importante. Si è creata una situazione in cui ambito, tempo e qualità sono al centro dell’attenzione.

Hai mai sentito di quel famoso esempio in cui il presidente Kennedy incontra un custode nella NASA e gli chiede cosa fa, e lui risponde: “Sto aiutando a mandare un uomo sulla luna”? Non è forse vero che avere questo tipo di persone nel progetto aiuta a rispettare la scadenza?

Man mano che procedi, assicurati che ogni singola area nel progetto contribuisca alla gestione del tempo. Non si può essere sufficientemente sicuri di rispettare la scadenza a meno che non si presti attenzione a tutti i settori.

Esempio: Cherry Picking (selezionare il meglio)

Quando si sperimentano vari approcci e metodi, a volte si selezionano gli elementi migliori fra i diversi riferimenti creando una combinazione di tutto ciò che sembra interessante. Questo generalmente non funziona, perché alcuni elementi non funzionano isolati dal loro riferimento e devono essere resi compatibili tra loro. Qualsiasi aggiunta o modifica a un sistema dovrebbe essere eseguita con una visione olistica.

Questo è il motivo per cui a volte vediamo elementi contraddittori in diversi metodi; qualcosa funziona bene in un sistema e il suo contrario funziona bene nell’altro sistema. Ogni elemento non è giusto o sbagliato a priori.

L’approccio più sicuro è selezionare una metodologia per la gestione del progetto, personalizzarla e poi aggiungere con cautela nuovi elementi, considerando la coerenza dell’intero sistema.

Esempio: l’approccio anti-processo

Una delle migliori cose che i metodi Agili hanno compiuto è portare l’attenzione sugli aspetti umani. Il manifesto Agile dà più valore ad essi rispetto ai processi e agli strumenti, anche se questi elementi non dovrebbero nemmeno essere comparati l’uno all’altro. Tutti i metodi affermano che gli aspetti umani sono importanti, ma la vera differenza nei metodi Agile è che gli aspetti umani sono parte integrante dei processi, piuttosto che un semplice suggerimento. Quindi, questa non è una competizione tra aspetti umani e processi, ma piuttosto sul modo in cui gli aspetti umani sono visti nel sistema.

È risaputo, alcune persone provano a sostituire gli aspetti umani con processi più sofisticati, ma questo è solo un uso improprio. Succede anche il contrario: ci sono persone che cercano di sostituire i processi con aspetti umani, cosa che comunque non funziona bene.

Esempio: questi sono tutte le aree di competenza di cui hai bisogno

Quando pensi alle aree di competenze, devi stare attento a non perderne nessuna. Ma quali sono? Se ti servi delle fonti più affermate riceverai risposte diverse, eppure nessuna di esse è pienamente valida.

I temi del PRINCE2® stabiliscono delle aree di competenza, ma sono solo quelle che svolgono un ruolo chiave nella metodologia. Le altre rimangono implicite. La Guida PMBOK® non rappresenta una metodologia vera e propria, ma la si evince bene dallo sviluppo di dieci aree di conoscenza riportate. Tuttavia, queste ultime rimangono interpretazioni basate sulla guida del PMBOK®, che non è neutrale (non che sia necessaria una prospettiva neutrale).

Cosi, per esempio, gli aspetti umani non ricevono molta attenzione nella Guida.

Una buona fonte di riferimento sulle aree di competenza è ICB (IPMA). Tuttavia, non si tratta di settori, ma di competenze richieste nel progetto. Non c’è una relazione diretta con i settori di competenza, anche se aiuta molto nell’identificarli.

Non esiste un elenco di settori nemmeno in NUPP, principalmente perché si tratta di un meta-sistema piuttosto che di un sistema, poi perché la categorizzazione dei domini dipende dal tipo di progetto e dal suo ambiente; ad esempio, un progetto di costruzione di routine può richiedere una prospettiva diversa rispetto a un progetto di ricerca creativa.


Non fare nulla senza uno scopo chiaro

Non dovresti fare nulla a meno che tu non abbia uno scopo chiaro. Immagina due mondi paralleli dove tutto è uguale tranne per la cosa che stai considerando: quanto sarebbero diversi? La differenza vale il tuo sforzo per fare quella cosa?

Se non hai uno scopo preciso in mente e fai qualcosa solo perché tutti gli altri lo stanno facendo, o tutti dicono che è importante farla, allora:

  • Potrebbe non esserci un reale vantaggio e quindi potresti non ottenere nulla da esso. Oppure
  • Potrebbe esserci ancora del potenziale beneficio, ma poiché non hai lo scopo chiaro in mente, il tuo modo di farlo potrebbe non essere efficace.

Esempio: Portfoli e Programmi

Se sei coinvolto nella selezione e nell’avvio di progetti, dovresti assicurarti di concentrarti sui benefici e sui problemi che dovrebbero essere risolti prima che il prodotto realizzi queste cose. L’esempio classico è il produttore di ascensori che riceveva lamentele sulla velocità dei loro ascensori e lanciava più progetti per aumentare la velocità, senza mai arrivare ad un successo completo. Così è andato avanti fino a quando non hanno deciso di capire il vero problema (la noia o il disagio della gente), anziché concentrarsi sulla soluzione “naturale” (ascensori più veloci). Il risultato è stato che aggiungendo specchi agli ascensori il problema e stato definitivamente risolto.

Ricorda che la gestione del progetto consiste principalmente nel fare le cose bene, mentre la gestione del portafoglio riguarda il fare le cose giuste. Non importa quanto bene gestisci i tuoi progetti, non funzionerà bene se stai facendo progetti sbagliati. Si tratta di avere chiaro lo scopo.

Esempio: il progetto nell’insieme

La flessibilità del prodotto varia nei progetti. In alcuni progetti di sviluppo IT il prodotto è completamente flessibile e la sua forma finale dipende dal feedback che verrà generato dagli incrementi del prodotto durante il progetto, per questo richiede un approccio adattivo (Agile). Questa è praticamente una combinazione del portfolio, del programma e dei livelli del progetto, e richiede la massima attenzione per raggiungere l’obiettivo finale. È una buona idea documentare lo scopo e renderlo accessibile; è uno degli scopi della “visione del prodotto” utilizzata in alcuni tipi di approcci al progetto, come quello Scrum. L’attenzione al valore del business nei progetti Agile è il loro modo di garantire l’allineamento con lo scopo.

In altri tipi di progetti, in cui il prodotto è relativamente fisso e vi sono altri meccanismi per garantire che il prodotto identificato soddisfi lo scopo, è possibile che i membri del team di progetto trasferiscano gran parte della loro attenzione dallo scopo al prodotto (da qui il principio “focus on products” di PRINCE2®). E’ richiesta comunque una minima attenzione allo scopo per garantire che ciò che viene costruito soddisferà lo scopo. Il che può essere fatto confrontando i benefici previsti con i benefici attesi (da qui il principio di “giustificazione aziendale continua” e il tema del ” business case” in PRINCE2®).

Quando il progetto è fatto per i clienti esterni, il cliente può avere il suo scopo nel fare il progetto e la tua azienda può averne uno diverso. Bisogna capire e usare entrambi per avere davvero successo.

Esempio: monitoraggio di progetto

Usare lo scopo finale è fondamentale, ma potrebbe essere troppo astratto per molti usi quotidiani. Ecco perché è necessaria una gerarchia di “elementi guida” per renderla più pratica. In primo luogo, la giustificazione e i benefici del progetto sono definiti in base allo scopo finale, perciò si avranno obiettivi espliciti e impliciti per le variabili del progetto (ad esempio tempo, costi e qualità) per soddisfare la giustificazione, che a sua volta soddisferà lo scopo ultimo. Questi sono obiettivi di livello inferiore che sono utili per molte delle nostre attività quotidiane.

Quando si tratta di monitoraggio, il monitoraggio di basso livello del progetto verrà eseguito utilizzando il livello più basso di variabili, perché potrebbe non essere possibile tracciare la correlazione con lo scopo finale. In questo caso, dovresti avere ancora in mente gli scopi: qual è lo scopo del monitoraggio?

Una risposta normale e accettabile è vedere se siamo sulla buona strada, altrimenti innescare una certa reazione che ci riporterà in pista o regolerà gli obiettivi e vedremo se può ancora soddisfare lo scopo finale. Pertanto, le nostre misurazioni dovrebbero essere in grado di aiutare, anche con questo scopo di basso livello e opportune misurazioni previsionali, al completamento delle variabili; cioè, quando saremmo in grado di terminare il progetto? Quanti soldi avremmo bisogno per finire il progetto? Eccetera.

Tutte le altre misurazioni, ad esempio i valori pianificati e attuali, sono solo valori transitori necessari per calcolare le previsioni, non i valori finali che si utilizzano a fini gestionali.

Esempio: documenti

Indipendentemente dall’approccio di sviluppo utilizzato nel progetto, la pianificazione è sempre necessaria. La questione importante è il livello di dettaglio in ciascuna tipologia di piano. Se non ci sono abbastanza dettagli nel piano, il piano non sarà in grado di contribuire a sufficienza e l’esecuzione del progetto sarà più basata su decisioni ad hoc piuttosto che su quelle olistiche e integrate. D’altro canto, molte persone cercano di essere caute e aggiungere troppi dettagli al loro piano, il che rende troppo difficile la preparazione e la manutenzione, rendendo tutto troppo rigido per le incertezze del progetto. Così, il piano diventa irrealistico e inutile.

Il modo migliore per decidere il livello di dettaglio è avere lo scopo in mente o ogni elemento del piano. Ad esempio, se stai considerando l’aggiunta di risorse al piano dovresti avere uno scopo: come le utilizzerai? Come potrebbe aiutare il progetto? Quanto impegno ci vuole? Ne vale la pena?

A volte si tratta di decidere se si desidera avere un determinato elemento nei piani e, a volte, come si desidera pianificare o preparare qualcosa. Prendi il Business Case, o il Project Charter, o un report: è ancora necessario chiederti perché stai preparando quel documento e come esso può aiutare il progetto.

Cercare di aderire ad un “modello” è l’opposto di fare qualcosa in funzione di uno scopo.

Esempio: status reporting (resoconto di stato)

In molti progetti è comune avere resoconti di stato del progetto davvero lunghi. Basandoci su NUPP, dovremmo chiederci quale sia lo scopo del resoconto e come possiamo raggiungere tale scopo a prescindere da ciò che la maggior parte degli altri potrebbe fare.

In molti casi, ciò può indurci a preparare resoconti di una sola pagina, molto semplici, che le parti interessate leggono e comprendono davvero, invece di lunghe relazioni. Questo significa che prestiamo attenzione agli scopi.

Tuttavia, se si preparano report di una sola pagina, alcune persone potrebbero obiettare e ritenere che non si disponga di un sistema di monitoraggio “appropriato”. Ciò crea praticamente un secondo scopo (oltre al primo scopo, che aiuta le parti interessate a capire lo stato del progetto). A tal fine puoi semplicemente creare un secondo tipo di resoconto più lungo, che non verrà comunque integrato con il primo perché i due scopi non sono identici.

Esempio: business case e project charter

Preparare documenti come un Business Case e un Project Charter è di solito, per la maggior parte delle persone, un impegno noioso, inutile, burocratico, mentre questi documenti hanno tutti scopi validi che si applicano alla maggior parte dei progetti. Se provi a prendere un “modello” e compilarlo, il lavoro è solo sprecato, puoi invece focalizzarti sullo scopo reale di quei documenti, vedere come e se possono essere utili nel tuo progetto, e quindi preparare il documento in qualsiasi modo tu voglia, solo per soddisfare tali scopi: il risultato sarà il documento giusto.

Mentre stai pensando al modo in cui puoi preparare i documenti per soddisfarne gli obiettivi, potresti non pensare ad ogni scenario col rischio di perdere qualcosa. E’ possibile trovare suggerimenti in alcuni riferimenti, quali PRINCE2®, PMBOK® Guide, e DSDM®, quindi valutare tali ipotesi in base agli obiettivi.

Esempio: dopo il progetto

Mentre il progetto ha un certo scopo, e lo possiamo considerare durante tutto il progetto, la realizzazione dello scopo finale è valutata principalmente sulla base delle previsioni effettuate durante il progetto, che non dovremmo dimenticare quando il progetto è completato. Questo è importante per verificare la realizzazione degli obiettivi dopo che il progetto è finito, perché:

  • possiamo vedere come vengono raggiunti gli obiettivi finali e apprendere insegnamenti preziosi per progetti futuri, e
  • talvolta gli obiettivi vengono raggiunti solo dopo aver aggiunto del lavoro successivo al completamento del progetto, è necessario comprendere la necessità di tali compiti extra durante il monitoraggio.

Il monitoraggio post-progetto è un passo necessario per assicurare l’ottenimento dello scopo. Di solito è responsabilità dei sistemi di gestione di programma e di portfolio, ma poiché la maggior parte delle aziende non ha tali livelli di gestione, questo passaggio viene solitamente trascurato. Ecco perché metodi come e DSDM® aggiungono questo passaggio alle loro metodologie di gestione di progetto.

Esempio: semplicità

Il mondo è complesso e caotico e i nostri modelli sono approssimazioni astratte che riflettono porzioni del mondo, pertanto possono essere semplici. D’altra parte, i sistemi semplici di solito funzionano meglio, perché possiamo concentrarci sull’idea principale. Molti di noi cercano di ottenere risultati migliori aggiungendo complessità ai nostri sistemi, sperando che si abbinino alla complessità del mondo, anche se questo praticamente rende il sistema difficile da operare e in genere impedisce di raggiungere l’obbiettivo.

Esempio: Tailoring (Adattamento)

I progetti non sono identici; un software per lo streaming di musica ha una condizione di funzionamento molto diversa da quella che potrebbe essere utilizzata nelle attrezzature di un ospedale, o da quella di un aereo, in cui la vita delle persone potrebbe dipendere da esso, o da un software utilizzato in un satellite realizzato per funzionare molti anni senza schiantarsi. E tutti questi sono diversi dalla costruzione di una villa estiva, di una stazione antincendio, o di un impianto di processo.

Quando hai in mente gli obiettivi, puoi comprendere meglio come personalizzare i sistemi e gli artefatti per i diversi progetti.


Utilizzare elementi ripetibili

Un approccio ad hoc per ogni progetto richiede troppe energie e risorse e presenta sempre il rischio di perdere alcuni degli elementi necessari. Il modo migliore per semplificare ciò che deve essere fatto è usare elementi ripetibili e preferibilmente portarli in cicli ripetibili.

Esempio: checklists (liste di controllo) di qualità

Una lista di controllo è un semplice esempio di un elemento potenzialmente ripetibile che molte persone usano nella loro vita personale e professionale. Prendi i criteri di qualità di un deliverable:

  • In primo luogo, è possibile creare una lista di controllo di tutti i criteri, che è anche una forma di pianificazione.
  • Quello che NUP6 consiglia è di provare a generalizzarlo: ci sono altri deliverable simili nel progetto? In tal caso, vale la pena di preparare una lista di controllo di qualità generale per quella categoria di prodotti finali, e usarla per tutti quei progetti. Se ci sono alcune varianti, bisogna mantenere l’elenco generico e aggiungi alcuni elementi extra per i singoli deliverable. In questo modo si ottengono elenchi di controllo ripetibili.
  • Quando si preparano liste di controllo generiche per vari tipi di risultati finali, è possibile trovare elementi che si ripetono tra loro, il che suggerisce per loro una virtuale categoria di livello superiore, diciamo “padre”. In tal caso, invece di ripetere gli articoli per tutte quelle liste di controllo generiche, si possono estrarre e inserire in una checklist principale. Infine, probabilmente si otterrà una sola checklist generica per l’intero progetto. La “Definition of Done” di Scrum è un esempio di checklist a livello di progetto, valida per la qualità, ma anche per altri temi. Ogni deliverable sarà declinato in una gerarchia di categorie, e dovrebbe soddisfare gli elementi visualizzati nelle checklist di tutte le categorie della catena.

In questo modo, un elemento nell’elenco di controllo principale diventerà ripetibile per tutti i deliverable sottostanti, risparmiando tempo ed energia nella pianificazione e nell’esecuzione. Ancora più importante, una volta fatto questo per un progetto, è possibile personalizzarlo e utilizzarlo per tutti i futuri progetti simili, così da ottenere una forma ripetibile di pianificazione per più progetti.

Esempio: processi e flussi di lavoro

Alcuni risultati o obiettivi richiedono al loro interno alcuni passaggi che possono diventare standardizzati e ripetibili. Ad esempio, se i deliverable devono essere progettati individualmente e approvati è possibile preparare un flusso di lavoro semplice che renda chiari tutti i passaggi, le persone coinvolte e le durate approssimate, evitando molte difficoltà. Si deve fare attenzione, tuttavia, a non rendere i flussi di lavoro e i processi troppo complicati o richiedenti troppa documentazione, poiché ciò avrebbe conseguenze negative. Tutte le persone coinvolte nel progetto dovrebbero trovare i flussi di lavoro e i processi come qualcosa che supporta il loro lavoro e rende tutto più facile. E non come una documentazione burocratica che blocca il loro vero lavoro.

I progetti Agili hanno elementi pratici ripetibili nel loro approccio di sviluppo iterativo, in cui alcuni tipi di attività di sviluppo vengono ripetuti per ogni funzione; per esempio, la routine quotidiana comune in XP (eXtreme Programming): accoppiare, selezionare un elemento, disegnarlo su una lavagna, creare script e codice di test, integrare il codice, ecc. Oltre ai flussi di lavoro ripetibili che possono essere utilizzati per attività tecniche, si possono avere elementi ripetibili anche per le attività di gestione del progetto. I processi nella Guida PMBOK®, PRINCE2® e DSDM®, le attività in e gli eventi in Scrum sono esempi di questo concetto.

Esempio: cicli

È utile disporre in modo chiaro gli elementi ripetibili per la gestione del progetto. Ciò può essere reso ancora più semplice inserendoli in cicli ripetibili. Questi cicli semplificano significativamente le attività quotidiane delle persone coinvolte nella gestione e nella leadership del progetto. Esempi di questo concetto sono: i cicli dei gruppi di processi nella Guida PMBOK®, quando utilizzati in un progetto con più fasi; le fasi (stages) nella metodologia PRINCE2®; i cicli giornalieri, settimanali e mensili in P3.Express; le iterazioni e i timebox in DSDM®; gli Sprint in Scrum.

Cicli più brevi sono più facili da capire e da usare rispetto a quelli più lunghi; ad esempio, Sprint in Scrum in contrasto con le fasi secondo la Guida PMBOK®. Tuttavia, cicli troppo brevi potrebbero non essere sufficienti per supportare determinati tipi di progetto e la soluzione può essere l’uso di più cicli, come in DSDM®, in cui si usano cicli di timebox brevi insieme a cicli di iterazione più lunghi, oppure come in, ove si usano cicli giornalieri, settimanali e mensili.

Esempio: metodi

L’utilizzo di una metodologia o di un framework per l’esecuzione di un progetto è un altro uso di elementi ripetibili. Questo può essere un sistema esistente come PRINCE2®,, DSDM® o Scrum, o uno che hai personalizzato o costruito da solo. Tuttavia, di solito è un’idea migliore iniziare con uno dei metodi esistenti e adattarlo alle proprie esigenze piuttosto che crearlo da zero.

Ogni elemento ripetibile è astratto e richiede la personalizzazione per adattarsi al mondo reale. Tuttavia c’è una gamma di necessità di astrazione e di personalizzazione: le checklist di qualità piccole e relativamente concrete si trovano all’estremità della gamma, con la minima quantità di astrazione e necessità di personalizzazione, mentre le metodologie sono dall’altra parte, con il più alto bisogno di adattamento. Si deve sempre analizzare la necessità di adattamento, altrimenti, l’elemento ripetibile non corrisponderà correttamente alle esigenze del caso.


Το NUPP είναι στην πραγματικότητα μια συλλογή από σχεδόν καθολικές αξίες που ισχύουν σε όλα τα έργα (projects): αυτές που ακολουθούνται σε όλα τα έργα, ανεξαρτήτως των μεθοδολογιών και προσεγγίσεων που χρησιμοποιούνται, με σκοπό τη μεγιστοποίηση της επιτυχίας.

Κάθε διαθέσιμη πηγή γνώσης και μεθοδολογία εκτέλεσης έργων, βασίζεται σε κάποιες από αυτές τις NUP (Nearly Universal Principles) αξίες, όμως:

  • Συνήθως δεν εφαρμόζονται όλες και θα ήταν χρήσιμο για τους επαγγελματίες να τις λαμβάνουν όλες υπ’ όψη και όχι μόνο ένα υποσύνολο από αυτές.

  • Οι υποκείμενες αξίες συνήθως δεν γίνονται ξεκάθαρες στις πηγές γνώσης (εγχειρίδια) και οι περισσότεροι επαγγελματίες εμπλέκονται σε πρακτικές λεπτομέρειες με αποτέλεσμα να απομακρύνονται από τις αξίες και να εκτελούν ενέργειες ασύμβατες με αυτές.

Το NUPP είναι συμβατό με όλες τις βασικές μεθοδολογίες, τα συστήματα, τις πηγές γνώσεων σχετικά με τη διαχείριση έργων και τα πλαίσια των PRINCE2®, PMBOK® Guide,, PM², DSDM®, XP και SCRUM. Παρ όλα αυτά μπορεί να μην είναι συμβατό με κάποιες παγιωμένες αντιλήψεις αυτών των συστημάτων και εκεί είναι που το NUPP προσπαθεί να παροτρύνει τους επαγγελματίες να επανεξετάσουν αυτές τις αντιλήψεις. Οι σχεδόν καθολικές αξίες του NUP (Nearly Universal Principles) είναι:


Προτίμηση στα αποτελέσματα και στην αλήθεια παρά στις σχέσεις

Όλοι έχουμε μια φυσική τάση να ανήκουμε σε ομάδες, η οποία πολύ συχνά πάει πέρα από τα όρια, δημιουργεί δυνατές σχέσεις και προκαλεί προβλήματα. Χάνουμε πολύ περισσότερα απ’ ότι κερδίζουμε εξαιτίας των σχέσεων. Μπορούμε να γίνουμε περισσότερο επαγγελματίες και αποδοτικοί, εάν δεν περιορίσουμε την ταυτότητα μας και τις προτιμήσεις μας σε συγκεκριμένες ομάδες.

Παράδειγμα: Agile vs Waterfall

Μια ομάδα ανθρώπων, με ενθουσιασμό και ταυτόχρονα αρκετά τολμηροί ώστε να προσπαθήσουν να υιοθετήσουν προσαρμοστικές προσεγγίσεις στο IT development, τη στιγμή που η επικρατούσα τάση ήταν η χρήση προγνωστικών προσεγγίσεων, συγκεντρώθηκαν και δημιούργησαν το Agile πλαίσιο. Αυτό ήταν ένα μεγάλο ξεκίνημα σε επιλογές χωρίς όρια, κάτι που άλλωστε φαινόταν απαραίτητο. Υπάρχουν ακόμη αρκετοί ενθουσιώδη και ταγμένοι στα αποτελέσματα στην Agile κοινότητα, αλλά δυστυχώς υπάρχουν και κάποιοι στη συγκεκριμένη κοινότητα που έχουν μετατρέψει το Agile σε «θρησκεία» και θεωρούν όλους τους υπόλοιπους ως εχθρούς. Το γεγονός αυτό προκαλεί πολλαπλά προβλήματα, μερικά από τα οποία είναι:

  • Δεν τους επιτρέπει να μαθαίνουν από κανέναν άλλον που δεν ανήκει στην κοινότητα
  • Αποθαρρύνει άλλους έξω από την κοινότητα να μαθαίνουν από αυτούς που ανήκουν στην κοινότητα
  • Μετατρέπει το να ανήκεις στην κοινότητα ποιο σημαντικό από τον πραγματικό σκοπό, που με τη σειρά του εμποδίζει πολλά από τα μέλη να μάθουν το πραγματικόν νόημα του Agility.

Το συγκεκριμένο πρόβλημα μπορεί να μειωθεί σημαντικά, αν όχι να μηδενιστεί, χρησιμοποιώντας όχι το “Agile” μόνο σαν ταμπέλα που αναφέρεται σε μια development προσέγγιση, αλλά σαν μια κοινότητα με μέλη και έχοντας ανθρώπους που θεωρούν τους εαυτούς τους δημιουργούς, επιλυτές προβλημάτων, και ηγέτες και έχουν το Agile σαν κάτι που έχουν μάθει και αφομοιώσει και όχι σαν την ταυτότητα τους.

Δεν υπάρχει πόλεμος Agile-Waterfall για ένα πραγματικό επαγγελματία.

Παράδειγμα: Prince2 vs PMBOK® Guide

Υπάρχουν αρκετοί επαγγελματίες που συνδέουν τον εαυτό τους είτε μόνο με το Prince2 είτε μόνο με το PMBOK® Guide (συνήθως εξαιτίας της γεωγραφικής περιοχής) και δεν είναι εξοικειωμένοι με το άλλο. Όλοι μπορεί να έχουμε προτιμήσεις σε συγκεκριμένες μεθοδολογίες, αλλά δε θα πρέπει να προσδιορίζουν την ταυτότητα μας και το ποιο σημαντικό θα πρέπει να εξοικειώνουμε τους εαυτούς μας με όλες, έτσι ώστε να διευρύνουμε τις αντιλήψεις και τις επιλογές μας.

Ο σωστός επαγγελματίας είναι ανοικτός σε όλες τις ιδέες, ψάχνει για αυτές, τις μαθαίνει και τις χρησιμοποιεί όποτε χρειάζεται χωρίς διασυνδέσεις.

Παράδειγμα: Δια βίου μάθηση

Οι σχέσεις ικανοποιούν τα άτομα μέσω του συναισθήματος ότι ανήκουν κάπου και δεν τους ωθούν να μάθουν, ενώ κάποιες φορές τους αποθαρρύνουν από τη μάθηση με το φόβο ότι οι ομάδες θα τους χάσουν. Ένα ελεύθερο άτομο, ένας επαγγελματίας χωρίς σχέσεις, αναπληρώνει το κενό με τη μάθηση: με τη δια βίου μάθηση.

Αυτό που πιστεύουμε σήμερα, δεν είναι η αλήθεια. Είναι μόνο αυτό που αντιλαμβανόμαστε όσο το δυνατόν καλύτερα, το οποίο και θα πρέπει να βελτιώνεται συνεχώς. Σε περίπτωση που οι ιδέες κάποιου είναι ακριβώς οι ίδιες με αυτές που είχε πριν μερικά χρόνια, τότε κάτι είναι λάθος. Αυτή είναι και η περίπτωση για το NUPP: Εάν έρθεις μετά από κάποια χρόνια και δεις ακριβώς τα ίδια, τότε θα πρέπει να γίνεις καχύποπτος.

Παράδειγμα: Δεκτικότητα

Όταν αντιπαρατίθεσαι με κάποιον άλλον, τότε βεβαιώσου ότι η αντίθεση σου κατευθύνεται προς την ιδέα και όχι προς το συγκεκριμένο άτομο. Αυτό βοηθάει στο να αποτρέπονται πολλές εντάσεις. Από την άλλη όταν κάποιος άλλος αντιπαρατίθεται με εσένα τότε προσπάθησε να το δεις όχι σαν πόλεμο εναντίον σου, αλλά σαν μια συζήτηση πάνω στην ιδέα σου και προσπάθησε να μείνεις δεκτικός. Μην ακούς για να απαντάς, αλλά για να καταλαβαίνεις και να δουλεύεις με τον άλλον έτσι ώστε να βελτιώνεται η ιδέα.

Εντούτοις, κάποιοι μπορεί να στοχεύουν συνειδητά εσένα αντί για την ιδέα. Στην περίπτωση αυτή βοήθησε τους να επικεντρωθούν στην ιδέα αντί για εσένα πριν να προχωρήσουν και προσπάθησε να το διατηρήσεις αυτό καθ΄ όλη τη συζήτηση.


Συντήρηση και βελτιστοποίηση της δυναμικής και των πόρων

Οι πόροι είναι περιορισμένοι. Οι πόροι που είναι διαθέσιμοι για το έργο είναι περιορισμένοι, όπως επίσης και η πνευματική ενέργεια που έχει κάποιος για να λαμβάνει σωστές αποφάσεις. Θα έπρεπε τα στοιχεία αυτά να συντηρούνται από τον καθένα για τον εαυτό του και το έργο και να βοηθάει και τους άλλους να κάνουν το ίδιο.

Παράδειγμα: Κανόνας 80/20

Ένα μεγάλο μέρος από τα πιθανά οφέλη της διοίκησης ενός έργου επιτυγχάνεται με ένα μικρό μέρος της συνολικής προσπάθειας. Στις περισσότερες περιπτώσεις, η επίτευξη του 100% από τα πιθανά οφέλη είναι πολύ δαπανηρό και αναιτιολόγητο. Πρέπει κανείς να λαμβάνει υπόψιν αυτόν τον κανόνα σε όλες τις ενέργειες και να ενθαρρύνει και άλλους να κάνουν το ίδιο.

Παράδειγμα: Καταπόνηση αποφάσεων

Χρησιμοποιούμε μόνο μία πηγή πνευματικής ενέργειας για όλες τις αποφάσεις που παίρνουμε όπως και για να τις εκφράσουμε. Εάν κάποιος χρησιμοποιεί το μεγαλύτερο μέρος αυτής της ενέργειας για μη απαραίτητες ή ασήμαντες αποφάσεις, θα απομείνει ένα πολύ μικρότερο μέρος για τις σημαντικές αποφάσεις και αυτό είναι πιθανό να οδηγήσει σε φτωχά αποτελέσματα. Αυτός είναι ένας από τους λόγους για τον οποίο θα πρέπει να αποτρέπεται η «μικρό-διοίκηση» (micro-management) (η διοίκηση κατ΄εξαίρεση σύμφωνα με τις αρχές του Prince2)

Οι διαμάχες σχετικά με τις ιδέες μπορεί να είναι χρήσιμες, ενώ αυτές που αφορούν ανθρώπους είναι συνήθως επιζήμιες για το έργο και μία από τις επιπτώσεις είναι ότι απορροφά την πνευματική ενέργεια των μελών της ομάδας. Εάν δει κάποιος μια τέτοια ενέργεια θα πρέπει να κάνει ότι μπορεί για να βρει την αιτία και να την επιλύσει.

Παράδειγμα: Φρόντισε τον εαυτό σου

Οι αποφάσεις που κάποιος παίρνει όπως και η θέληση που εκφράζει, χρησιμοποιούν σαν πηγή την πνευματική του ενέργεια. Από την άλλη αυτή η ενέργεια αναπληρώνεται όταν κάποιος κοιμάται και τρέφεται επαρκώς. Οπότε, φρόντισε σωστά τον εαυτό σου: Επιβεβαίωσε ότι ο ύπνος σου και η τροφή σου είναι επαρκή και τρέφεσαι καλά. Εάν υπάρχουν τραυματικές συνήθειες ή προβλήματα με τον ύπνο, μπορείς να μην τα αντιμετωπίσεις μόνος σου: υπάρχουν ειδικοί που μπορούν να βοηθήσουν να τα αντιμετωπίσεις ευκολότερα. Η φυσική δραστηριότητα μπορεί επίσης να βοηθήσει στην αναπλήρωση της πνευματικής ενέργειας, αλλά οι μελέτες δεν έχουν ακόμη καταλήξει.

Προσπάθησε να ενθαρρύνεις τα μέλη της ομάδας να πράττουν το ίδιο με σένα. Πρώτα επιβεβαίωσε ότι εργάζονται με ένα σταθερό ρυθμό, χωρίς υπερβολική υπερεργασία. Έπειτα, εάν υπάρχει η δυνατότητα προσπάθησε να προσφέρεις ενέργεια, υγιή φαγητό, ενδιάμεσα γεύματα και χυμούς κατά τη διάρκεια της εργασίας.

Παράδειγμα: Ισορροπία προσωπικής ζωής και εργασίας

Πολλοί από εμάς αγαπάνε αυτό που κάνουνε, αλλά δεν πρέπει να είναι μόνο αυτό που έχουμε στη ζωή. Με τον ίδιο τρόπο που βελτιστοποιούμε την εργασία μας, θα πρέπει να σχεδιάζουμε και να υλοποιούμε τις ιδέες στην προσωπική μας ζωή, με έναν τρόπο που θα την κάνει ευχάριστη και χαρούμενη. Όταν είσαι πιο ευτυχισμένος, μπορείς επίσης να είσαι και πιο επιτυχημένος στην εργασία σου. Εάν μπορείς, προσπάθησε να ενθαρρύνεις και τα υπόλοιπα μέλη της ομάδας σου να κάνουν το ίδιο.

Παράδειγμα: Παρότρυνση

Η παρότρυνση είναι μια πολύπλοκη ιδέα. Υπάρχουν κάποιες ενδιαφέρουσες και χρήσιμες πηγές πληροφοριών στο συγκεκριμένο θέμα, όπως επίσης και πολλές περισσότερο μη-επιστημονικές. Ωστόσο, θα πρέπει κάποιος να μάθει το συγκεκριμένο αντικείμενο και να το χρησιμοποιεί συνεχώς, αφού αυξάνει την πνευματική ενέργεια της ομάδας και την πιθανότητα επίτευξης καλύτερων αποτελεσμάτων για το έργο.

Η παρότρυνση μπορεί να είναι τόσο απλή, όσο το να αναγνωρίζεις στους άλλους την καλή εργασία με ένα ευγενικό χαμόγελο ή ένα απλό «ευχαριστώ». Όμως, πρέπει κάποιος να είναι προσεκτικός, διότι πολλές από τις κοινές ιδέες παρότρυνσης, όπως για παράδειγμα μικρά χρηματικά βραβεία, μπορεί να έχουν αρνητικό αντίκτυπο.

Παράδειγμα: Συνεργασία και ομαδική δουλειά

Οι άνθρωποι που συνεργάζονται, μπορεί κάποιες φορές να έχουν τη δύναμη να δημιουργήσουν καλύτερα αποτελέσματα, αλλά το πιο σημαντικό είναι ότι οι άνθρωποι είναι κοινωνικοί και προτιμούν να είναι μέρος μιας ομάδας. Εάν μπορείς να αφαιρέσεις τις αρνητικές διαστάσεις της ομαδικής εργασίας και να δημιουργήσεις ένα ευχάριστο περιβάλλον, τότε όλα τα μέλη της ομάδας του έργου θα είναι πιο ευτυχισμένα.

Θα πρέπει να είσαι προσεκτικός και σκληρός, διότι οι άνθρωποι είναι διαφορετικοί και κάποιοι χρειάζονται περισσότερο άνετο, εστιασμένο και απομονωμένο χρόνο από άλλους; συνήθως είναι μια πράξη ισορροπίας.

Παράδειγμα: Κουλτούρα της μιας ομάδας

Υπάρχει μια τάση όπου οι διάφοροι ενδιαφερόμενοι προσπαθούν να δημιουργήσουν ή να θεωρήσουν υπο-ομάδες και να προκαλέσουν εντάσεις με άλλες ομάδες, για παράδειγμα οι άνθρωποι που εστιάζουν στις επιχειρηματικές διαστάσεις του έργου vs αυτών που κατασκευάζουν το έργο. Αυτή η ένταση καταναλώνει πολύ ενέργεια και από τις δύο πλευρές, και αυτός είναι ένας από τους λόγους που θα πρέπει να χτίζουμε την κουλτούρα της μιας ομάδας, όπου δουλεύουν όλοι μαζί προς τον κοινό στόχο.

Παράδειγμα: Η σοφία του πλήθους

Όταν ένας μεγάλος αριθμός διαφορετικών ατόμων συνεργάζονται σε ένα συγκεκριμένο περιβάλλον, υπάρχει η δυναμική να έχουμε πολύ καλά αποτελέσματα, ιδέες και λύσεις πολύ καλύτερα από αυτά που προκύπτουν από μεμονωμένους ειδικούς.

Εάν έχεις αυτήν την άποψη, μπορείς να τη χρησιμοποιείς συχνά και να ζητάς από τα μέλη της ομάδας τη βοήθεια για την επίλυση δύσκολων προβλημάτων στο έργο. Παράλληλα με την πιθανότητα της επίτευξης καλών αποτελεσμάτων, επιτρέπει επίσης στα μέλη της ομάδας να γνωρίζουν ότι οι απόψεις τους εκτιμώνται και ότι παίζουν ένα σημαντικό ρόλο στο έργο, που με τη σειρά του αυξάνει τα επίπεδα της ενέργειας τους στο έργο. Η δραστηριότητα #26 του είναι ένα παράδειγμα χρησιμοποίησης της σοφίας του πλήθους στα έργα

Παράδειγμα: Chief Project facilitator

Εάν είσαι project manager, οι περισσότερες από τις ενέργειες που κάνεις έχουν τη μορφή διευκόλυνσης (ή τουλάχιστον θα έπρεπε να έχουν). Από την άλλη, μπορεί να διαπιστώνεις ότι τα μέλη της ομάδας είχαν κακές εμπειρίες στο παρελθόν με project managers και αυτές οι εμπειρίες έχουν επιπτώσεις στις σχέσεις τους με εσένα: ένα μέρος της ενέργειας τους αναλώνεται στην ανάλυση της συμπεριφοράς σου για εν δυνάμει απειλές, αντί να σε εμπιστεύονται. Στην περίπτωση αυτή μπορείς να αλλάξεις τον τίτλο σου από project manager σε Chief Project facilitator. Τελικά, αυτό είναι που πραγματικά κάνεις στο έργο.


Πάντα να υπάρχει προληπτική δράση

Υπάρχει σε όλους μας μια φυσική τάση για προληπτική δράση. Μπορεί να μας βοηθήσει να συντηρήσουμε την ενέργεια μας αντιμετωπίζοντάς ασήμαντά θέματα, όπως και μπορεί να μας δώσει καλυτέρα αποτελέσματα όταν αντιμετωπίζουμε κάτι στο οποίο είμαστε εντελώς ακατάλληλοι. Οι καταστάσεις αυτές είναι διαφορετικές από τα έργα που έχουμε, και εδώ μπορούμε να έχουμε καλύτερα αποτελέσματα με το να προλαμβάνουμε καταστάσεις.

Παράδειγμα: Προγραμματισμός

Εάν θέλεις να οδηγήσεις προς μια άγνωστη τοποθεσία και έχεις αργοπορήσει, μπορείς να αρχίσεις να οδηγείς αμέσως για να γλιτώσεις χρόνο και να αντιμετωπίζεις τα πιθανά προβλήματα όταν προκύπτουν. Η προληπτική προσέγγιση είναι να αφιερώσεις κάποιο χρόνο αρχικά για να ρυθμίσεις το σύστημα πλοήγησης έτσι ώστε να σου προσδιορίσει τη γρηγορότερη διαδρομή, με βάση την κίνηση και τα πιθανά ατυχήματα και κυκλοφοριακά εμφράγματα και μετά να οδηγήσεις; ξοδεύοντας έτσι χρόνο πριν για να αποφύγεις προβλήματα αργότερα και γλιτώνοντας έτσι χρόνο τελικά.

Σε αντίθεση με ότι πιστεύουν κάποιοι σχετικά με τα Agile έργα, ο προγραμματισμός είναι πάντα απαραίτητος, και έχει να κάνει μόνο με το είδος και τα επίπεδα λεπτομέρειας του προγράμματος. Ο προγραμματισμός πριν από την εκτέλεση είναι μια προληπτική προσέγγιση.

Θυμηθείτε την φράση: δώστε μου έξι ώρες για να κόψω ένα δένδρο και θα ξοδέψω τις πρώτες τέσσερεις ακονίζοντας το τσεκούρι.

Εάν έχουμε ένα έργο προληπτικής δράσης, οι τέσσερεις ώρες μπορεί να ξοδευτούν ακονίζοντας το τσεκούρι, διότι είσαι σίγουρος ότι θα κόψεις ένα δένδρο. Σε ένα Agile έργο, δεν είσαι σίγουρος εάν θα κόψεις το δένδρο, συγκεντρώσεις τα σπασμένα κλαδιά, μαζέψεις το γρασίδι, εξορύξεις κάρβουνο ή κάνεις κάτι άλλο. Παρόλα αυτά, είναι επίσης απαραίτητο να έχεις μια γενική προετοιμασία για όλα αυτά (γνωρίζεις που βρίσκεται η κοντινότερη αποθήκη εξοπλισμού), όπως και να έχεις μια συγκεκριμένη προετοιμασία (ακόνισμα) όταν θα στοχεύσεις σε μια συγκεκριμένη λύση; αυτό είναι ο προγραμματισμός.

Παράδειγμα: Προγραμματίζοντας τον Προγραμματισμό

Προγραμματίζοντας τον τρόπο με τον οποίο θα εκτελέσουμε το έργο είναι μια προληπτική προσέγγιση. Η προληπτική αυτή προσέγγιση μπορεί ακόμη και να επεκταθεί μέχρι τον προγραμματισμό του τρόπου με τον οποίο θα προγραμματίσουμε την εκτέλεση; Αυτή είναι η ιδέα της διαχείρισης πλάνου του PMBOK® Guide, οι στρατηγικές διαχείρισης του PRINCE2® και οι προσεγγίσεις στο DSDM®.

Παράδειγμα: Διαχείριση κινδύνου

Η όλη ιδέα της διαχείρισης κινδύνου βασίζεται στην προληπτική προσέγγιση: όταν αντιμετωπίζεις αβέβαια γεγονότα, είναι προτιμότερο από το να περιμένεις να δεις τι θα γίνει και μετά να αντιδράσεις, να σκεφτόμαστε τις σχετικές πιθανότητες, τις επιπτώσεις, να εξετάζουμε αντιδράσεις και ίσως να κάνουμε κάτι για αυτό προτού συμβεί.

Σημειώστε ότι το πως ενεργούμε στα έργα είναι πολύ σοβαρό; Κάποιες φορές έχει να κάνει με τις ζωές ανθρώπων.

Παράδειγμα: Προσδιορισμός ρόλων και ευθυνών

Μπορεί κάποιος να αφήσει τα μέλη της ομάδας του έργου να δουλεύουν χωρίς ξεκάθαρους ρόλους και ευθύνες και αργά η γρήγορα θα προκύψει η ανάγκη καθορισμού ρόλων και ευθυνών, αλλά τότε θα έχει κόστος και δε θα λειτουργήσει σωστά. Η προληπτική δράση είναι αυτά να οριστούν νωρίς και να καθοριστούν όπως πρέπει. Το γεγονός αυτό κάνει την εργασία για όλους ευκολότερη και όλοι μπορούν να επικεντρωθούν στο να παράγουν αντί να αποφασίζουν ποιος θα κάνει τι.

Ο αριθμός και η ποικιλία των ρόλων εξαρτάται από το είδος και το μέγεθος του έργου; μπορεί να είναι ένας απλός ορισμός όπως συμβαίνει στο Scrum, κάτι μέτριο όπως στο ή κάτι πιο ευρύ όπως συμβαίνει στο DSDM® και στο PRINCE2®. Όμως, μην ξεχνάτε ότι οι περιγραφές των ρόλων σε αυτές τις μεθόδους, αφορούν μόνο τις δραστηριότητες διαχείρισης και ότι πάντα θα πρέπει να προσθέτετε περιγραφές ρόλων και για τις τεχνικές διαστάσεις του έργου.

Παράδειγμα: Διαθέσιμες Επιλογές

Πρέπει να κλείσει ένα έργο πρόωρα ή να συνεχιστεί?

Σπάνια υπάρχουν μόνο δύο επιλογές ακόμη και αν η ερώτηση υπονοεί κάτι τέτοιο. Θα πρέπει να υπάρχει μια προληπτική προσέγγιση και να εξετάζονται όλες οι επιλογές προτού ληφθεί μια απόφαση. Μπορεί να επαναπροσδιοριστεί ο σκοπός του έργου, μπορεί να σταματήσει προσωρινά έως ότου κάτι άλλο ξεκαθαρίσει, ή μπορεί να μεταβληθεί η προσέγγιση του έργου (πχ ανάθεση σε εξωτερικό συνεργάτη), κτλ

Παράδειγμα: Κριτική σκέψη

Όλοι έχουμε πολλές έμφυτες τάσεις, που από τη μία μας οδηγούν στο να επιβιώσουμε, αλλά από την άλλη μας εξαπατούν λαμβάνοντάς κακές αποφάσεις. Όταν έρθει η ώρα να πάρουμε σημαντικές αποφάσεις όσον αφορά το έργο, είναι προτιμότερο να σταματάμε προσωρινά για ένα διάστημα και να εξετάζουμε όλες τις έμφυτες τάσεις που έχουμε και μπορούν να επηρεάσουν την απόφαση μας, προτού μας προκαλέσουν προβλήματα.

Σαν αναφορά, μπορεί να χρησιμοποιηθεί η λίστα με τις διανοητικές τάσεις που υπάρχουν στη Wikipedia:

Υπάρχουν ακόμη και πλαίσια λήψης αποφάσεων που μπορείς να χρησιμοποιήσεις για να λάβεις καλύτερες αποφάσεις. Αρχικά, μπορεί να φαίνεται απωθητικό και ενοχλητικό η χρήση αυτών, αλλά σύντομα θα τα συνηθίσεις και θα μπορείς να αποκτάς πλεονέκτημα χωρίς ιδιαίτερη προσπάθεια.

Παράδειγμα: Διαφάνεια

Δε μας αρέσει να αργοπορούμε σε ένα έργο ή να έχουμε άλλου είδους προβλήματα, αλλά αυτό δε σημαίνει ότι θα πρέπει να τα κρύβουμε κιόλας. Θα πρέπει να επιτρέπεις τη διαφάνεια αλλά και τους ενδιαφερόμενους να γνωρίζουν, διότι κάποιοι από αυτούς μπορεί να είναι ικανοί να σε βοηθήσουν και επιπρόσθετα θα γνωρίζουν σχετικά με τα προβλήματα και τις συνέπειες τους συντομότερα ή αργότερα και κάποιοι από αυτούς μπορεί να απαιτήσουν σύντομα ενέργειες από την πλευρά τους (πχ να αποδεχτούν τις αρνητικές επιπτώσεις)

Παράδειγμα: Επικοινώνησε αποδοτικά

Υπάρχει πιθανότητα, όπου σε πολλές περιπτώσεις στέλνεις αναφορές σε διάφορους ενδιαφερόμενους αλλά δεν απαντούν. Μπορεί να πιστεύεις ότι όλα βαίνουν καλώς διότι δε λαμβάνεις αρνητική απάντηση, αλλά αυτό μπορεί να μη συμβαίνει. Πρέπει να προλαμβάνεις και να ελέγχεις εάν πραγματικά έχουν χρησιμοποιήσει τις αναφορές και εάν έχουν υπηρετήσει το σκοπό, έτσι ώστε να προσαρμόζεις ανάλογα και τη μέθοδο επικοινωνίας; Διαφορετικά αυτό το κρυμμένο ζήτημα είναι δυνατό να προκαλέσει σοβαρά προβλήματα αργότερα όπου θα είναι πολύ δύσκολη η επίλυσή τους.

Παράδειγμα: Πάρε ευθύνη

Είναι ευκολότερο να κατηγορείς άλλους για τα άσχημα αποτελέσματα. Για παράδειγμα μπορεί να επιθυμείς ο οργανισμός να σου δώσει πλήρη εξουσιοδότηση για να τα αλλάξεις όλα στο έργο και να γίνουν όλα τέλεια, αλλά δε σου τη δίνουν και σαν αποτέλεσμα το έργο αποτυγχάνει. Αυτή δεν είναι προληπτική προσέγγιση.

Η προληπτική προσέγγιση είναι να αναλαμβάνεις την ευθύνη και να κάνεις όλα όσα μπορείς μέσα στους δεδομένους περιορισμούς. Δεν είναι δυνατόν να περιμένεις ο οργανισμός να σου δώσει τα πάντα και να σε εμπιστευτεί πλήρως με την ελπίδα ότι θα πάρει καλά αποτελέσματα, ειδικά όταν έχουν δει τόσα αποτυχημένα έργα. Αυτό που πρέπει να κάνεις είναι μια μικρή πρόοδο μέσα στα όρια που έχουν τεθεί, την οποία μπορείς να χρησιμοποιήσεις για να κερδίσεις λίγο την εμπιστοσύνη, μερικούς ακόμη πόρους και μια μικρή ανεκτικότητα στα όρια που μπορείς έπειτα να χρησιμοποιήσεις για μια ελαφρώς μεγαλύτερη πρόοδο, συνεχίζοντας έτσι ώσπου να φτάσεις στον βέλτιστο στόχο.


Κάθε αλυσίδα είναι τόσο δυνατή όσο είναι ο πιο αδύναμος της κρίκος

Υπάρχουν διάφορες περιοχές σε ένα έργο και όλες απαιτούν προσοχή; πρέπει να έχουμε μια ολιστική αντίληψη για το έργο. Δίνοντας προσοχή σε μια φαινομενικά σημαντική περιοχή (πχ χρόνος) δεν είναι αρκετό, διότι όλες οι περιοχές αλληλοεπιδρούν και δε λειτουργούμε σωστά εκτός και αν όλες λάβουν την κατάλληλη προσοχή.

Παράδειγμα: Όλα γίνονται για την καταληκτική ημερομηνία

Ας θεωρήσουμε ότι κατασκευάζετε κάτι για τους Ολυμπιακούς Αγώνες. Έχει μια πολύ σημαντική καταληκτική ημερομηνία, η οποία κάνει τη διαχείριση χρόνου πολύ σημαντική. Είναι αυτό το σωστό, όμως?

Τι θα γίνει εάν η ποιότητα είναι τόσο κακή που απαιτεί την επανάληψη εργασίας μετά από κάποιο διάστημα. Αυτό θα έχει επίπτωση στο χρόνο, έτσι χρόνος και ποιότητα συνδέονται. Μπορεί να έχεις ένα φανταστικό κήπο να συμπεριλαμβάνεται στον αρχικό ορισμό του έργου, αλλά να ξέρεις ότι αν δεν υπάρχει διαθέσιμος χρόνος, μπορείς να το παραλείψεις και απλά να το καλύψεις με γρασίδι, όσο έχεις προνοήσει για αυτήν την πιθανότητα στον χρόνο και την έχεις προετοιμάσει. Έτσι, η διαχείριση του σκοπού του έργου είναι επίσης σημαντική. Έτσι, μέχρι τώρα έχουμε τις περιοχές του σκοπού, της ποιότητας και του χρόνου στο κέντρο της προσοχής μας.

Έχετε ακούσει για το διάσημο παράδειγμα όπου ο πρόεδρος Κένεντυ, συναντά έναν επιστάτη στη NASA και τον ρωτά με τι ασχολείται και εκείνος του απαντά «Βοηθάω να στείλω τον άνθρωπο στο φεγγάρι». Δε βοηθάει να έχουμε τέτοιους τύπους ανθρώπων στο έργο στο να πετύχουμε την καταληκτική προθεσμία?

Όσο θα συνεχίζεις, θα διαπιστώνεις ότι κάθε συγκεκριμένη περιοχή του έργου, συμβάλει στη διαχείριση του χρόνου, και δε μπορεί κάποιος να πετύχει την τελική προθεσμία με αποδεκτή βεβαιότητα, εκτός και αν δώσει προσοχή σε όλες τις περιοχές του έργου.

Παράδειγμα: Cherry Picking

Όταν οι άνθρωποι έρχονται αντιμέτωποι με μια γκάμα μεθόδων, μερικές φορές αρχίζουν να επιλέγουν (cherry picking) και δημιουργούν μια μίξη από όλα, δείχνοντας ενδιαφέρον από διάφορα συστήματα. Αυτό συνήθως δε δουλεύει, διότι τα στοιχεία δε λειτουργούν απομονωμένα και πρέπει να είναι συμβατά μεταξύ τους. Κάθε προσθήκη ή αλλαγή σε ένα σύστημα θα πρέπει να γίνεται από μια ολιστική αντίληψη.

Έτσι για αυτό μερικές φορές παρατηρούμε αντικρουόμενα στοιχεία σε διαφορετικές μεθόδους; Κάτι λειτουργεί καλά σε ένα σύστημα και το αντίθετο του λειτουργεί επίσης καλά σε ένα άλλο σύστημα. Το συγκεκριμένο στοιχείο δεν θεωρείται σωστό ή λάθος από μόνο του.

Η ασφαλέστερη προσέγγιση είναι η επιλογή μιας μεθόδου για το έργο, η προσαρμογή της στο έργο και η προσθήκη προσεκτικά νέων στοιχείων σε αυτό λαμβάνοντας υπόψιν τη σταθερότητα όλου του συστήματος.

Παράδειγμα: Η προσέγγιση της αντι-διαδικασίας

Ένα από τα σπουδαιότερα πράγματα που οι Agile μέθοδοι έχουν επιτύχει, είναι να δώσουν προσοχή στα θέματα του προσωπικού. Το Agile manifesto δίνει περισσότερη αξία στα μεμονωμένα άτομα και στις αλληλεπιδράσεις σε σύγκριση με τις διαδικασίες και τα εργαλεία, παρόλο που αυτό μπορεί να μην είναι μια δίκαιη σύγκριση. Σχεδόν όλες οι μέθοδοι, λένε ότι τα θέματα προσωπικού είναι σημαντικά, αλλά η πραγματική διαφορά με τις Agile μεθόδους είναι ότι τα θέματα προσωπικού αποτελούν ένα αναπόσπαστο τμήμα των διαδικασιών, παρά μια απλή υπόδειξη. Έτσι, δεν πρόκειται για ένα διαγωνισμό μεταξύ των θεμάτων του προσωπικού και των διαδικασιών, αλλά περισσότερο για τον τρόπο με το οποίο τα θέματα αυτά γίνονται αντιληπτά από το σύστημα.

Δεν υπάρχει αμφιβολία ότι κάποιοι προσπαθούν να αντικαταστήσουν τα θέματα προσωπικού με πιο εκλεπτυσμένες διαδικασίες, αλλά αυτό είναι λάθος. Υπάρχει επίσης και η αντίθετη περίπτωση: κάποιοι να προσπαθούν να αντικαταστήσουν διαδικασίες με θέματα προσωπικού το οποίο επίσης δεν λειτουργεί.

Παράδειγμα: Αυτές είναι όλες οι περιοχές που χρειάζεσαι

Όταν σκεφτόμαστε τις περιοχές θα πρέπει να είμαστε προσεκτικοί να μην χάσουμε καμία από αυτές. Τι είναι όμως αυτές? Εάν ελέγξεις τις βασικές πηγές γνώσης, θα λάβεις διαφορετικές απαντήσεις, και ακόμη καμία από αυτές δεν είναι όλη η αλήθεια.

Τα θέματα του PRINCE2® είναι περιοχές, αλλά αυτές αποτελούν περιοχές που παίζουν σημαντικό ρόλο μόνο στη συγκεκριμένη μεθοδολογία. Οι υπόλοιπες περιοχές μόνο υπονοούνται. Το PMBOK® Guide δεν αποτελεί μεθοδολογία και μπορεί να το διατυπώσει πολύ καλύτερα με τις δέκα περιοχές γνώσης. Όμως, αυτές είναι απλά ερμηνείες όλων των περιοχών βασισμένες στην αντίληψη του PMBOK® Guide, παρά μιας ουδέτερης (όχι ότι απαραίτητα υπάρχει και κάποια ουδέτερη). Για παράδειγμα, τα θέματα προσωπικού δε λαμβάνουν ιδιαίτερη προσοχή στο PMBOK® Guide.

Μια καλή πηγή πληροφοριών σχετικά με τις περιοχές είναι το ICB. Όμως στην πραγματικότητα δεν είναι για τις περιοχές, αλλά για τις ικανότητες που απαιτούνται στο έργο. Δεν έχει μια σχέση ένας-με-έναν με τις περιοχές, αλλά βοηθάει πολύ στην αναγνώριση τους.

Δεν υπάρχει μια λίστα με τις περιοχές στο NUPP, κυρίως επειδή πρόκειται για ένα μετα-σύστημα παρά για ένα σύστημα και διότι η κατηγοριοποίηση των περιοχών εξαρτάται από το είδος του έργου και το περιβάλλον του; Πχ ένα συνηθισμένο έργο κατασκευής μπορεί να απαιτεί μια διαφορετική αντίληψη από ένα δημιουργικό έργο έρευνας.


Μην κάνεις κάτι χωρίς ξεκάθαρο σκοπό

Δεν θα πρέπει να κάνεις κάτι, εκτός και αν υπάρχει ξεκάθαρος σκοπός. Φαντάσου δύο παράλληλους κόσμους όπου τα πάντα είναι τα ίδια εκτός από αυτό με το οποίο ασχολείσαι: Πόσο διαφορετικοί θα μπορούσαν να είναι αυτοί οι κόσμοι? Αξίζει αυτή η διαφορά την προσπάθεια την οποία κάνεις?

Εάν δεν υπάρχει ξεκάθαρος σκοπός στο μυαλό σου και κάνεις κάτι επειδή το κάνουν όλοι οι άλλοι ή το λένε όλοι ότι είναι σημαντικό να το κάνεις, τότε:

  • Μπορεί να μην υπάρχει κάποιο όφελος στην δική σου περίπτωση και επιπρόσθετα μπορεί να μην κερδίσεις τίποτα

  • Μπορεί να έχει δυνητικά οφέλη στην περίπτωση σου, αλλά επειδή δεν υπάρχει ο σκοπός στο μυαλό σου, ο τρόπος που ενεργείς μπορεί να μη σε βοηθήσει να αντιληφθείς τα οφέλη

Παράδειγμα: Χαρτοφυλάκια και Προγράμματα

Εάν σχετίζεσαι με την επιλογή και την αρχικοποίηση έργων, θα πρέπει να σιγουρεύεις ότι επικεντρώνεσαι στα κέρδη και στα προβλήματα που πρέπει να επιλυθούν, παρά στο παραγόμενο προϊόν από το οποίο προκύπτουν. Κλασικό παράδειγμα αποτελεί εκείνο του κατασκευαστή ασανσέρ, που λάμβανε παράπονα για την ταχύτητά των ασανσέρ και έτσι έτρεχε διάφορα έργα για την αύξηση της ταχύτητας χωρίς ιδιαίτερη επιτυχία. Αυτό συνεχίστηκε έως ότου αποφάσισαν να επικεντρωθούν στο πρόβλημα (πλήξη ή δυσφορία των ανθρώπων), παρά στην ουδέτερη λύση (ταχύτερα ασανσέρ). Το αποτέλεσμα ήταν η προσθήκη καθρεφτών στα ασανσέρ, με αποτέλεσμα την απλή και φτηνή επίλυση του προβλήματος.

Θυμηθείτε ότι η διαχείριση έργων είναι κυρίως η εκτέλεση των ενεργειών σωστά, ενώ η διαχείριση των χαρτοφυλακίων έχει να κάνει με το να κάνεις τις σωστές ενέργειες. Δεν έχει σημασία πόσο σωστά τρέχεις τα έργα σου; δε θα λειτουργήσει σωστά εάν εκτελείς λάθος έργα. Έχουν να κάνουν όλα με το να υπάρχει ένας σκοπός.

Παράδειγμα: Έργο σαν ολότητα

Η ευελιξία του παραγόμενου προϊόντος ποικίλει μεταξύ διαφόρων έργων. Σε κάποια IT development έργα, το προϊόν είναι εντελώς ευέλικτο και η τελική του μορφή εξαρτάται από την ανατροφοδότηση που θα δημιουργηθεί από τις αλλεπάλληλες αυξήσεις (increments) του προϊόντος κατά τη διάρκεια του έργου, το οποίο και απαιτεί μια προσαρμοστική (Agile) προσέγγιση. Αυτό σε πρακτικούς όρους σημαίνει έναν συνδυασμό των επιπέδων τού έργου, του χαρτοφυλακίου και του προγράμματος και απαιτεί να υπάρχει μέγιστη προσοχή προς τον απόλυτο στόχο. Είναι μια καλή ιδέα η καταγραφή του σκοπού και η εύκολη πρόσβαση της; Αυτός είναι ένας από τους στόχους του «οράματος προϊόντος» όπως συνηθίζεται να χρησιμοποιείται σε κάποια Scrum έργα. Η προσοχή στην επιχειρηματική αξία στα Agile έργα, αποτελεί στην ουσία τον τρόπο με τον οποίο διασφαλίζουν την ευθυγράμμιση με τον σκοπό.

Σε άλλου τύπου έργα, όπου το παραγόμενο προϊόν είναι σχετικά αμετάβλητο και υπάρχουν άλλοι μηχανισμοί έτσι ώστε να διασφαλίσουν ότι το παραγόμενο τελικό προϊόν θα ικανοποιεί το σκοπό για τον οποίο δημιουργήθηκε, είναι πιθανό για τα μέλη της ομάδας του έργου να μετατοπίσουν ένα μεγάλο μέρος της προσοχής τους από τον σκοπό στο παραγόμενο προϊόν (Ως εκ τούτου και η βασική αξία του PRINCE2® “εστίαση στα προϊόντα»), αλλά παρόλα αυτά, μια ελάχιστη εστίαση στο σκοπό απαιτείται ακόμη και σε αυτήν την περίπτωση έτσι ώστε να διασφαλιστεί ότι ικανοποιεί το σκοπό, το οποίο και επιτυγχάνεται συγκρίνοντας τα προβλέψιμα με τα προσδοκόμενα οφέλη (Ως εκ τούτου και η βασική αξία του PRINCE2® «συνεχή επιχειρηματική αιτιολογία» αλλά και το «Business Case» θέμα του PRINCE2®).

Όταν ένα έργο τρέχει για έναν εξωτερικό πελάτη, ο πελάτης θα έχει τον δικό του ξεχωριστό σκοπό για το έργο, ενώ η εταιρεία σου θα έχει ένα διαφορετικό σκοπό. Θα πρέπει να καταλάβεις και να χρησιμοποιήσεις και τα δύο έτσι ώστε να πετύχεις πραγματικά.

Παράδειγμα: Επιτήρηση έργου

Η εστίαση στον απόλυτο σκοπό είναι απαραίτητη, αλλά μπορεί να είναι πολύ αφηρημένη για πολλές από τις καθημερινές χρήσεις. Για το λόγο αυτό απαιτείται μια ιεραρχία από οδηγούς έτσι ώστε να καταστεί περισσότερο πρακτική. Αρχικά, ορίζονται η αιτιολόγηση και τα οφέλη του έργου με βάση τον απόλυτο σκοπό και έπειτα θα υπάρξουν έμμεσοι αλλά και ξεκάθαροι στόχοι για τις μεταβλητές του έργου (πχ χρόνος, κόστος και ποιότητα) για την ικανοποίηση της αιτιολογίας (justification) που με τη σειρά της θα ικανοποιήσει τον απόλυτο σκοπό. Αυτοί είναι στόχοι χαμηλότερου επιπέδου οι οποίοι και είναι χρήσιμοι για πολλές από τις καθημερινές εργασίες.

Όταν ερχόμαστε στην επιτήρηση, η χαμηλότερου επιπέδου επιτήρηση πραγματοποιείται χρησιμοποιώντας τις χαμηλότερου επιπέδου μεταβλητές, διότι μπορεί να μην είναι πιθανό να ανιχνευτεί ο απόλυτος σκοπός. Στην περίπτωση αυτή θα πρέπει επίσης να υπάρχουν οι στόχοι κατά νου: ποιος είναι ο σκοπός της επιτήρησης?

Μια σωστή και αποδεκτή απάντηση είναι να εξετάσουμε εάν είμαστε στο σωστό δρόμο και αν δεν είμαστε, να προκαλέσουμε μια βέβαιη αντίδραση που θα μας επαναφέρει στο σωστό δρόμο ή να προσαρμόσουμε τους στόχους και να εξετάσουμε εάν ακόμη μπορούν να ικανοποιήσουν τον απόλυτο σκοπό. Επιπρόσθετα, οι μετρήσεις μας, θα πρέπει να είναι ικανές να μας βοηθήσουν με το χαμηλότερου επιπέδου σκοπό και οι κατάλληλες μετρήσεις είναι προβλέψεις για τις μεταβλητές κατά την ολοκλήρωση πχ πότε θα είμαστε ικανοί να ολοκληρώσουμε το έργο? Πόσα χρήματα θα χρειαστούμε για την ολοκλήρωση του έργου? Όλες οι υπόλοιπες μετρήσεις, όπως οι σχεδιαζόμενες και οι πραγματικές τιμές μέχρι σήμερα, είναι απλά προσωρινές τιμές που απαιτούνται για τον υπολογισμό των προβλέψεων, και όχι οι τελικές τιμές που χρησιμεύουν για διαχειριστικούς σκοπούς.

Παράδειγμα: Έγγραφα

Ανεξαρτήτως της development προσέγγισης που χρησιμοποιείται στο έργο, ο προγραμματισμός είναι πάντα απαραίτητος. Η σημαντική ερώτηση είναι το επίπεδο της λεπτομέρειας σε κάθε είδους πλάνου. Εάν δεν υπάρχει επαρκή λεπτομέρεια στο πλάνο, το πλάνο δε θα είναι ικανό να συμβάλει αρκετά, και η υλοποίηση του έργου θα βασίζεται σε ad hoc αποφάσεις και όχι σε ολοκληρωμένες και ολιστικές. Από την άλλη, αρκετοί προσπαθούν να είναι προσεκτικοί και προσθέτουν υπερβολική λεπτομέρεια στα πλάνα, προκαλώντας δυσκολία στη δημιουργία και συντήρηση τους αλλά και καθιστώντας τα άκαμπτα στις αβεβαιότητες του έργου. Σαν αποτέλεσμα το πλάνο γίνεται μη ρεαλιστικό και άχρηστο.

Ο καλύτερος τρόπος για να αποφασίσεις για το επίπεδο της λεπτομέρειας είναι να έχεις ένα σκοπό στο μυαλό για κάθε στοιχείο στο πλάνο. Για παράδειγμα, εάν εξετάζεις την προσθήκη πόρων στο πλάνο, θα πρέπει να έχεις ένα στόχο για αυτό; Πώς πρόκειται να το χρησιμοποιήσεις? Πώς το συγκεκριμένο γεγονός θα βοηθήσει το έργο? Πόση προσπάθεια θα χρειαστεί? Και εν τέλει αξίζει?

Κάποιες φορές σχετίζεται με την απόφαση εάν θέλεις να έχεις ένα συγκεκριμένο στοιχείο στα πλάνα σου και κάποιες φορές σχετικά με τον τρόπο που θέλεις να προγραμματίσεις ή να ετοιμάσεις κάτι. Είτε πρόκειται για ένα business case, είτε για ένα χάρτη έργου, είτε για μια αναφορά: θα πρέπει να διερωτάται κανείς για ποιο λόγο ετοιμάζει το συγκεκριμένο έγγραφο και πως θα μπορέσει να βοηθήσει το έργο.

Ψάχνοντας για ένα «πρότυπο» είναι το αντίθετο από το να κάνεις κάτι με βάση ένα σκοπό.

Παράδειγμα: Αναφορά κατάστασης

Είναι σύνηθες να έχουμε πραγματικά μεγάλες αναφορές κατάστασης σε πολλά έργα. Βασισμένο σε αυτό το NUP, θα πρέπει να διερωτόμαστε ποιος ο σκοπός της συγκεκριμένης αναφοράς και πως μπορούμε να επιτύχουμε τον συγκεκριμένο σκοπό, ανεξαρτήτως του τι κάνουν οι περισσότεροι.

Αυτό, σε πολλές περιπτώσεις, μπορεί να μας οδηγήσει στο να ετοιμάζουμε πολύ απλές, μιας σελίδας αναφορές, τις οποίες οι ενδιαφερόμενοι πραγματικά διαβάζουν και καταλαβαίνουν, σε σχέση με μακροσκελείς αναφορές. Αυτό είναι η επικέντρωση στο σκοπό.

Όμως, αν ετοιμάζεις αναφορές μιας σελίδας, κάποιοι μπορούν να σου εναντιωθούν και να πιστέψουν ότι δεν έχεις ένα πρέπον σύστημα επιτήρησης σε λειτουργία. Στην πράξη, αυτό δημιουργεί για εσένα ένα δεύτερο σκοπό (επιπρόσθετα του πρώτου σκοπού, που είναι η βοήθεια στους ενδιαφερόμενους να κατανοήσουν την κατάσταση του έργου) και για να τον εκπληρώσεις, μπορείς απλά να δημιουργήσεις ένα δεύτερο είδος αναφοράς που θα είναι πολύ πιο μακροσκελής. Όμως, δε θα πρέπει να αναμιχθεί με την προηγούμενη πρώτη αναφορά, διότι οι σκοποί τους δεν είναι οι ίδιοι.

Παράδειγμα: Business Case και Χάρτης έργου

Ετοιμάζοντας έγγραφα όπως το business case και ο χάρτης έργου είναι συνήθως μια βαρετή, ατελέσφορη και γραφειοκρατική αναγκαιότητα για τους περισσότερους ανθρώπους, ενώ όλα αυτά τα έγγραφα έχουν έγκυρους στόχους που εφαρμόζονται στα περισσότερα έργα. Εάν προσπαθήσεις να βρεις ένα υπόδειγμα και κάθε φορά να το συμπληρώνεις, απλά ο χρόνος ξοδεύεται; Ενώ από την άλλη θα μπορούσες να ελέγξεις τον πραγματικό σκοπό αυτών των εγγράφων, να δεις αν και πως μπορούν να καταστούν χρήσιμα για το έργο σου και μετά να προετοιμάσεις το έγγραφο με τον τρόπο που προτιμάς, μόνο και μόνο για να εκπληρώσεις τους συγκεκριμένους στόχους: αυτό θα ήταν το κατάλληλο έγγραφο.

Ενώ σκέφτεσαι τον τρόπο προετοιμασίας των εγγράφων για την εκπλήρωση των στόχων, είναι δυνατό να μη σκεφτείς κάθε σενάριο και κάτι να παραλείψεις. Για να το αποτρέψεις αυτό, μπορείς να ελέγξεις τι αναφέρουν διαφορετικές πηγές γνώσεων όπως το PRINCE2®, PMBOK® Guide, και DSDM®-προτείνει, και έπειτα να εκτιμήσεις τις προτάσεις αυτές με βάση τους στόχους.

Παράδειγμα: Μετά το έργο

Ενώ το έργο έχει ένα συγκεκριμένο στόχο, και μπορούμε να εξετάσουμε τον συγκεκριμένο στόχο κατά τη διάρκεια του έργου, η συνειδητοποίηση του στόχου εκτιμάται κυρίως με βάση τις προβλέψεις που γίνονται κατά τη διάρκεια του έργου. Δεν θα πρέπει παρόλα αυτά να τον ξεχνάμε όταν το έργο ολοκληρώνεται. Είναι σημαντικός ο έλεγχος της συνειδητοποίησης των στόχων μετά την ολοκλήρωση του έργου, διότι

  • Μπορούμε να δούμε πώς οι απόλυτοι στόχοι επιτευχθήκαν και να μάθουμε από αυτό για μελλοντικά έργα
  • Μερικές φορές οι στόχοι επιτυγχάνονται μόνο όταν εκτελούμε κάποιες επιπρόσθετες εργασίες μετά την ολοκλήρωση του έργου και η κατανόηση της αναγκαιότητας αυτών των επιπρόσθετων εργασιών απαιτεί επιτήρηση

Η επιτήρηση μετά το έργο είναι ένα απαραίτητο βήμα στο να οδηγούμαστε σύμφωνα με το στόχο. Είναι κυρίως ευθύνη του συστήματος διαχείρισης του προγράμματος και του χαρτοφυλακίου και επειδή οι περισσότερες εταιρίες δεν διαθέτουν τέτοια επίπεδα διαχείρισης, αυτό το βήμα συνήθως αμελείται. Αυτός είναι και ο λόγος που μέθοδοι όπως το και DSDM® προσθέτουν το συγκεκριμένο βήμα στις μεθοδολογίες τους διαχείρισης έργων.

Παράδειγμα: Απλότητα

Ο κόσμος είναι πολύπλοκος και χαοτικός, αλλά τα μοντέλα μας είναι αφηρημένες προσεγγίσεις που αντανακλούν τμήματα του κόσμου και επομένως μπορεί να είναι απλά. Από την άλλη, τα απλά συστήματα συνήθως λειτουργούν καλύτερα, διότι μπορούμε να επικεντρωθούμε στην κύρια ιδέα.

Πολλοί από εμάς προσπαθούν να επιτύχουν καλύτερα αποτελέσματά, προσθέτοντας πολυπλοκότητα στα συστήματα, ελπίζοντάς ότι έτσι θα ταιριάξουν την πολυπλοκότητα του κόσμου, ακόμη και αν στην πράξη αυτό κάνει το σύστημα δύσκολο να συνεργαστεί και συνήθως μας εμποδίζει από την ικανοποίηση του στόχου.

Παράδειγμα: Προσαρμογή

Ένα κομμάτι λογισμικού (software) για μουσική streaming έχει μια τελείως διαφορετική συνθήκη από ένα άλλο που θα χρησιμοποιηθεί για εξοπλισμό σε ένα νοσοκομείο ή αεροπλάνο, όπου οι ζωές των ανθρώπων θα εξαρτώνται από αυτό, ή από ένα κομμάτι λογισμικού που θα χρησιμοποιηθεί σε έναν δορυφόρο όπου θεωρείται ότι θα λειτουργήσει για πολλά χρόνια δίχως να χαλάσει και όλα είναι διαφορετικά στο να χτίζεις μια καλοκαιρινή βίλλα, έναν σταθμό πυροσβεστικής ή ένα σταθμό ενέργειας.

Όταν υπάρχουν οι στόχοι κατά νου, θα καταλάβεις καλύτερα πώς να προσαρμόζεις τα συστήματα και τα αποτελέσματα για διαφορετικά έργα.


Χρησιμοποίησε στοιχεία που έχουν χρησιμοποιηθεί στο παρελθόν

Μια ad hoc προσέγγιση έργου απαιτεί αρκετή ενέργεια και πόρους και πάντα υπάρχει το ρίσκο της παράλειψης κάποιων από τα απαραίτητα στοιχεία. Ο καλύτερος τρόπος απλοποίησης του τι πρέπει να γίνει, είναι η χρήση στοιχείων που έχουν επαναχρησιμοποιηθεί στο παρελθόν, και προτιμητέο να τα παίρνει κάποιος σε επαναλήψιμους κύκλους.

Παράδειγμα: Λίστες Ποιότητας

Μία λίστα είναι ένα απλό παράδειγμα ενός δυνητικά επαναλήψιμου στοιχείου που πολλοί άνθρωποι χρησιμοποιούν στην προσωπική και επαγγελματική τους ζωή. Πάρτε για παράδειγμα τα κριτήρια ποιότητας ενός παραδοτέου:

  • Πρώτα δημιουργείτε μια λίστα με όλα τα κριτήρια που είναι μια μορφή προγραμματισμού
  • Αυτό που προτείνει το NUP6 είναι η προσπάθεια γενίκευσής: υπάρχουν άλλα παρόμοια παραδοτέα στο έργο? Στην περίπτωση αυτή προετοιμάστε μια γενική λίστα ποιότητας για αυτήν την κατηγορία παραδοτέων και χρησιμοποιείστε την για όλα αυτά. Εάν υπάρχουν κάποιες διαφοροποιήσεις, κρατήστε τη γενική λίστα και προσθέστε μερικά ακόμη σημεία για κάθε ένα παραδοτέο. Τώρα έχετε επαναλήψιμες λίστες.
  • Από τη στιγμή που έχετε ετοιμάσει γενικές λίστες για διαφορετικού τύπου παραδοτέα, μπορεί να διαπιστώσετε ότι υπάρχουν στοιχεία που επαναλαμβάνονται μεταξύ αυτών, το οποίο συνιστά μια εικονική γονική κατηγορία για αυτά. Στην περίπτωση αυτή, αντί να επαναλαμβάνονται τα σημεία για όλες αυτές τις γενικές λίστες, μπορείτε να τα απομονώσετε και να τα τοποθετήσετε σε μια γονική λίστα. Στο τέλος, πολύ πιθανό να έχετε μια μόνο γενική λίστα για όλο το έργο. Ο ορισμός του “done” στο Scrum αποτελεί ένα παράδειγμα χρήσης λιστών ποιότητας σε επίπεδο έργου (πιθανότατα μεταξύ άλλων πραγμάτων). Κάνοντας αυτό, κάθε παραδοτέο θα ανήκει σε μια ιεραρχία από κατηγορίες και θα πρέπει να ικανοποιεί τα σημεία που εμφανίζονται στις λίστες όλων των κατηγοριών στις αλληλουχίες τους.

Επίσης κάνοντας αυτό, ένα σημείο στην γονική λίστα θα γίνεται επαναλαμβανόμενο για όλα τα παραδοτέα που βρίσκονται από κάτω, πράγμα το οποίο γλυτώνει χρόνο και ενέργεια στον προγραμματισμό και στην εκτέλεση.

Το πιο σημαντικό είναι ότι από τη στιγμή που αυτό γίνεται σε κάποιο έργο, μπορείς να το προσαρμόσεις και να το χρησιμοποιήσεις σε παρόμοια έργα στο μέλλον, το οποίο είναι μια επαναλήψιμη μορφή προγραμματισμού για πολλαπλά έργα.

Παράδειγμα: Διαδικασίες και ροές εργασιών

Κάποια παραδοτέα ή στόχοι που συνδέονται με αυτά, χρειάζονται συγκεκριμένα βήματα τα οποία μπορούν να κανονικοποιηθούν και να επαναλαμβάνονται. Για παράδειγμα, εάν τα παραδοτέα πρέπει να σχεδιαστούν ανεξάρτητα και να εγκριθούν, μπορεί να σχεδιαστεί μια απλή ροή εργασίας που θα καταστήσει όλα τα βήματα, του ανθρώπους που αναμιγνύονται και τις διάρκειες ξεκάθαρες, αποτρέποντας πολλές δυσκολίες. Θα πρέπει όμως να δοθεί προσοχή έτσι ώστε οι ροές εργασιών και οι διαδικασίες να μη γίνουν πολύ πολύπλοκες ή πολύ ευαίσθητες στην καταγραφή, αφού αυτό θα έχει αρνητικές επιπτώσεις. Όλοι οι συμμετέχοντες στο έργο, θα πρέπει να βλέπουν τις ροές εργασιών και τις διαδικασίες σαν κάτι που υποστηρίζει την εργασία τους και κάνει τα πάντα ευκολότερα για αυτούς, παρά σαν μια γραφειοκρατική καταγραφή που εμποδίζει την πραγματική εργασία.

Τα Agile έργα έχουν επαναλαμβανόμενα στοιχεία στην επαναλαμβανόμενη τους development προσέγγιση, όπου βεβαίου τύπου development δραστηριότητες επαναλαμβάνονται για κάθε χαρακτηριστικό; πχ η κοινή καθημερινή ρουτίνα στο XP (eXtreme Programming): ταίριαξε, πάρε ένα τμήμα, σχεδίασε το στον πίνακα, χτίσε τα τεστ scripts και τον κώδικα, ενσωμάτωσε τον κώδικα, κτλ Επιπροσθέτως των ροών εργασιών που επαναλαμβάνονται και μπορούν να χρησιμοποιηθούν για τεχνικές δραστηριότητες, μπορείς επίσης να έχεις επαναλαμβανόμενα στοιχεία για τις δραστηριότητες διαχείρισης έργου. Οι διαδικασίες στο PMBOK® Guide, PRINCE2® και DSDM®, οι διαδικασίες στο και τα γεγονότα στο Scrum είναι παραδείγματα της συγκεκριμένης ιδέας.

Παράδειγμα: Κύκλοι

Έχοντας επαναλήψιμα στοιχεία για τη διαχείριση του έργου είναι κάτι χρήσιμο. Αυτό μπορεί να γίνει ακόμη ευκολότερο βάζοντάς τα σε επαναλαμβανόμενους κύκλους. Οι συγκεκριμένοι κύκλοι απλοποιούν σημαντικά τις καθημερινές δραστηριότητες των ανθρώπων που εμπλέκονται στη διαχείριση και ηγεσία του έργου. Κύκλοι των ομάδων διαδικασιών του PMBOK® Guide όταν χρησιμοποιούνται σε ένα έργο με πολλαπλές φάσεις, στάδια στο PRINCE2®, καθημερινούς, εβδομαδιαίους, μηνιαίους κύκλους στο, επαναλήψεις και timeboxes στο DSDM®, και sprints στο Scrum είναι όλα παραδείγματα αυτής της ιδέας.

Οι μικρότεροι κύκλοι είναι ευκολότερο να κατανοηθούν και να χρησιμοποιηθούν σε σχέση με τους μεγαλύτερους; Πχ τα sprints στο Scrum σε αντίθεση με τις φάσεις (phases) σύμφωνα με το PMBOK® Guide. Όμως, οι κύκλοι που είναι πολύ μικροί μπορεί να μην είναι επαρκείς για να υποστηρίξουν συγκεκριμένους τύπους έργων και η λύση μπορεί να είναι η χρήση πολλαπλών κύκλων, όπως η χρήση του μικρών timebox κύκλων του DSDM®, παράλληλα με μεγαλύτερους κύκλους επανάληψης, ή χρήση των καθημερινών, εβδομαδιαίων, μηνιαίων κύκλων του

Παράδειγμα: Μέθοδοι

Η χρήση κάποιας μεθοδολογίας ή πλαισίου για τη διαχείριση έργου είναι μια άλλη χρήση των επαναλήψιμων στοιχείων. Αυτό μπορεί να είναι ένα υπάρχον σύστημα όπως το PRINCE2®,, DSDM® ή SCRUM ή κάποιο άλλο που έχει εξατομικευτεί ή χτιστεί για τον εαυτό σου. Όμως κανονικά είναι καλύτερη ιδέα, να ξεκινήσεις με κάποια μεθοδολογία που ήδη υπάρχει και να την προσαρμόσεις στις ανάγκες σου, παρά να την φτιάξεις από την αρχή.

Κάθε επαναλήψιμο στοιχείο είναι αφηρημένη έννοια και χρειάζεται εξατομίκευση για να προσαρμοστεί στον πραγματικό κόσμο. Υπάρχει ένα ευρύ φάσμα αφηρημένης έννοιας και ανάγκης για εξατομίκευση, ωστόσο: μικρές, σχετικά συμπαγείς λίστες ελέγχου βρίσκονται στο ένα άκρο του φάσματος με το μικρότερο εύρος αφηρημένης έννοιας και ανάγκης προσαρμογής, ενώ οι μεθοδολογίες βρίσκονται στο άλλο άκρο, με την υψηλότερη ανάγκη προσαρμογής. Πρέπει πάντα να σημειώνεται η ανάγκη για προσαρμογή, διαφορετικά το επαναλήψιμο στοιχείο δε θα καλύπτει τις ανάγκες σου σωστά.


NUPP هو مجموعة من القواعد العامة تقريبا للمشاريع: تلك التي من المحبذ اتباعها في جميع المشاريع بغض النظر عن المنهجيات و الأساليب التي نعتمدها لزيادة نجاحنا.

ينتبه كل مورد وطريقة لإدارة المشاريع إلى بعض من هاته NUPs (قواعد عامة تقريبًا)، ومع ذلك:

  • عادة ليس جميعهم، وسيكون من الجيد للممارسين استعمال جميع NUPs بدلاً من مجموعة فرعية، و
  • عادة ما تكون المبادئ الأساسية غير واضحة بما فيه الكفاية في الموارد، ويهتم معظم الممارسين في التفاصيل العملية التي تنسى المبادئ وتفعل أشياء لا تتوافق معها.

NUPP متوافق مع جميع الطرق والأنظمة والموارد والأطر الرئيسية مثل PRINCE2® و PMBOK® Guide و و PM² و DSDM® و XP و Scrum. على الرغم من أنه قد لا يكون متوافقًا مع تفسيرات معينة لتلك الأنظمة، وهنا يحاول NUPP تشجيع الممارسين على إعادة النظر في تفسيراتهم. NUPs هم:


تفضيل النتائج والحقيقة على الانتماءات

لدينا جميعًا ميلًا طبيعيًا للانتماء إلى مجموعات، والتي غالبًا ما تتجاوز شكلها الأساسي، وتخلق انتماءات قوية، وتسبب مشاكل. نخسر أكثر بكثير مما نربحه بسبب هذه الانتماءات. يمكننا أن نصبح خبراء أكثر احترافية وفعالية إذا لم نقصر هويتنا وتفضيلاتنا على مجموعات معينة.

مثال: Agile vs Waterfall

مجموعة من الأشخاص المتحمسين الذين كانت لديهم الشجاعة لتجربة أسلوب التنمية التكيفية في تطوير تكنولوجيا المعلومات بالرغم من ان المعيار المتبع حينها كان أسلوب التنبؤ، اجتمعوا وأطلقوا على اسلوبهم اسم Agile.

كانت هذه مبادرة رائعة لعدم تقصير الخيارات على ما بدا أنه ضروري. لا يزال هناك الكثير من الأشخاص المتحمسين والموجهين نحو تحقيق النتائج في منظمة Agile، ولكن لسوء الحظ، هناك أيضًا بعض الأشخاص في هذه المنظمة يحولون Agile إلى عبادة ويعتبرون جميع الغرباء أعداء.

هذا يسبب مشاكل بطرق متعددة، بما في ذلك ما يلي:

  • لا يستطيعون التعلم من أي شخص خارج المجموعة
  • لا يشجع الاخرين على التعلم منهم
  • يجعل الانتماء الى المجموعة اهم بكثير من الهدف الحقيقي والذي بدوره يمنع العديد من أعضائها من تعلم المعنى الحقيقي ل Agility

يمكن تقليل هذه المشكلة بشكل كبير، إن لم تتم إزالتها بشكل كامل، عن طريق استخدام “Agile” فقط كتسمية تشير إلى اسلوب تطوير بدلاً من مجموعة أعضاء؛ وعن طريق ايجاد أشخاص يعتبرون أنفسهم مبدعين، ويمكنهم حل المشكلات، وقادة، يرون أن Agile ببساطة هو من أحد العوامل التمكينية تحت نطاقهم بدلاً من هويتهم.

ليست هناك حرب Agile-waterfall للمحترفين الحقيقيين.

مثال: PRINCE2® vs PMBOK® Guide

هناك العديد من المهنيين في المجتمع الذين يربطون أنفسهم إما بالدليل PRINCE2® أو PMBOK® (عادة بسبب موقعهم الجغرافي) وليسوا على دراية ببقية الأساليب.

يمكن أن يكون لدينا جميعًا تفضيلات تجاه موارد معينة، ولكن ليس باعتبارها هويتنا، والأهم من ذلك، يجب أن نتعرف عليهم جميعًا لتوسيع منظورنا وخياراتنا.

المحترف الحقيقي هو منفتح على كل الأفكار، يبحث عنها، يتعلم عنها ويستخدمها عند الحاجة بدون انتماءات.

مثال: تعليم مستمر

ترضي الانتماءات الشخص بسبب الشعور بالانتماء الذي تولده، ولكن لا تدفعه إلى التعلم، وأحيانًا لا يشجعه على التعلم خوفًا من فقدانه. عندما تكون شخصًا حرًا، أو خبيرًا بدون انتماءات، يجب أن تملأ الفجوة بالتعلم: بالتعلم المستمر.

ما نؤمن به اليوم ليس هو الحقيقة. إنه مجرد فهمنا الأفضل حتى الآن، والذي يجب تحسينه مع تقدمنا. عندما تكون أفكار الشخص هي نفسها تمامًا كما كانت عليه قبل بضع سنوات فيوجد حتما خطأ ما. هذا هو الحال بالنسبة لـ NUPP: إذا عدت بعد بضع سنوات وشاهدت نفس الشيء بالضبط، فيجب أن تشك.

مثال: الانفتاح

عند الاعتراض على شخص ما، تأكد ان اعتراضك هو على الفكرة وليس الشخص. هذا يساعد على منع الكثير من التوترات.

في سياق مشابه، عندما يعترض شخص ما عليك، لا تحاول أن تفسرها على أنها حرب ضدك، بل هي مناقشة لأفكارك، ويجب ان تكون منفتح عليها. لا تستمع للرد، ولكن استمع إلى الفهم؛ واعمل مع الشخص الآخر لتحسين الفكرة.

قد يستهدفك بعض الأشخاص عن قصد بدلاً من الفكرة، وفي هذه الحالة، يجب أن تساعدهم على التركيز على الفكرة بدلاً من التركيز عليك، وحاول الاحتفاظ بهذا الأسلوب خلال المحادثة.


الحفاظ على الطاقة والموارد وتحسينها

الموارد محدودة. الموارد المتاحة للمشروع محدودة، وكذلك الطاقة العقلية التي لديك لاتخاذ قرارات جيدة. يجب عليك الحفاظ على هذه الموارد وتحسينها لنفسك وللمشروع، ومساعدة أعضاء الفريق الآخرين على القيام بنفس الشيء.

مثال: القاعدة 80/20

يمكن تحقيق جزء كبير من الفوائد المحتملة لإدارة المشروع عن طريق بذل قليل من المجهود. في معظم الحالات، يكون استهداف 100٪ من الفوائد المحتملة باهظ التكلفة وغير مبرر. يجب تطبيق هذه القاعدة في كل ما نقوم به وحث البقية على القيام بنفس الشيء.

مثال: القرار عند التعب

نحن نستخدم مصدرًا وحيدًا للطاقة العقلية لاتخاذ جميع أنواع القرارات، وأيضًا للتعبير عن قوة الإرادة. إذا كنت تستهلك الكثير من هذا المصدر في اتخاذ قرارات غير ضرورية أو غير مهمة، فستكون لديك طاقة أقل لاتخاذ القرارات المهمة، مما قد يؤدي إلى نتائج سيئة. هذا أحد الأسباب التي تجعلك تتجنب الإدارة الصغرى (مبدأ “manage by exception” في PRINCE2®).

يمكن أن تكون النزاعات التي تدور حول الأفكار مفيدة، ولكن تلك التي تدور حول أشخاص عادة ما تكون ضارة للمشروع، ومن عواقب ذلك أنه يستنزف الطاقة العقلية لأعضاء الفريق. إذا لاحظت مثل هذه النزاعات، فعليك بذل قصارى جهدك للعثور على السبب الجذري وحله.

مثال: اهتم بنفسك

إن القرارات التي تتخذها وقوة الإرادة التي تعبر عنها تستخدم مصدر الطاقة العقلية لديك. من ناحية أخرى، يمتلئ هذا المصدر بالطاقة عند النوم وتناول الطعام بشكل صحيح. لذا، يجب أن تعتني بنفسك جيدًا: تأكد من حصولك على قسط كافٍ من النوم والراحة، وتناول الطعام جيدًا. إذا كانت لديك عادات أو مشاكل ضارة في النوم، فلا يتعين عليك التعامل معها بمفردك؛ هناك العديد من المختصين الذين يمكنهم مساعدتك في حل هذه المشاكل. قد يساعد النشاط البدني أيضًا في هذا المصدر للطاقة، على الرغم من أن الدراسات لم تصل بعد إلى نتيجة حاسمة في هذا الشأن.

حاول تشجيع أعضاء الفريق على القيام بنفس الشيء الذي تقوم به. أولاً، تأكد من أنهم يعملون بوتيرة مستدامة ودون الكثير من الوقت الإضافي. ثم، إذا كان لديك الخيار، فحاول تقديم طعام صحي ووجبات خفيفة ومشروبات أثناء اوقات العمل.

مثال: توازن الحياة مع العمل

الكثير منا يحب ما يفعله، لكن هذا ليس كل ما نحتاج إليه في الحياة. بنفس الطريقة التي تعمل بها على تحسين عملك، يجب أن تخطط وتنفذ الأفكار في حياتك الشخصية، بطرق تجعلها سعيدة وممتعة. عندما تكون أكثر سعادة، يمكنك أن تكون أكثر نجاحًا في العمل أيضًا. إذا استطعت، فحاول تشجيع أعضاء فريقك على فعل الشيء نفسه.

مثال: التحفيز

التحفيز مفهوم معقد. هناك بعض الموارد المفيدة حول هذا الموضوع، بالإضافة إلى العديد من المصادر غير العلمية. ومع ذلك، يجب عليك معرفة ذلك واستخدامه بشكل مستمر، لأنه يزيد من الطاقة العقلية للفريق وإمكانية تحقيق نتائج أفضل للمشروع.

يمكن أن يكون التحفيز بسيطًا مثل إخبار الناس أنك ممتن لعملهم الجيد بابتسامة لطيفة أو “شكر” بسيط. ومع ذلك، عليك أن تكون حذراً، لأن العديد من الأشكال الشائعة لتحفيز، مثل المكافآت النقدية الصغيرة، لها تأثير سلبي.

مثال: التعاون والعمل الجماعي

قد يكون للأشخاص المتعاونين في بعض الأحيان القدرة على تحقيق نتائج أفضل، ولكن الأهم من ذلك، أن البشر اجتماعيون ويستمتعون بالانتماء الى المجموعة. إذا تمكنت من إزالة الجوانب السلبية للعمل الجماعي وخلق بيئة ممتعة، فسيكون هناك أعضاء أكثر سعادة في المشروع.

يجب أن تكون حذرًا، لأن الناس مختلفون، والبعض يحتاج إلى وقت أكثر استرخاءً وتركيزًا وعزلة من غيرهم؛ إنه عادةً عمل موازنة.

مثال: ثقافة الفريق الواحد

هناك ميل للمساهمين في المشروع لإنشاء مجموعات فرعية والتسبب في توتر مع المجموعات الأخرى؛ على سبيل المثال، الأشخاص الذين يركزون على الجوانب التجارية للمشروع مقابل الأشخاص الذين يبنون المنتج. يستهلك هذا التوتر الكثير من الطاقة من كلا الجانبين، وهذا أحد الأسباب التي تجعلنا نحاول بناء ثقافة فريق واحد، حيث يعمل الجميع معًا لتحقيق نفس الهدف.

حكمة الحشد

عندما تلتقي مجموعة من الأشخاص المتنوعين ثقافيًا ويعملون في البيئة المناسبة، يكون من الممكن تحقيق نتائج جيدة جدًا وأفكار جيدة وأحيانًا حلول أفضل من تلك التي يقدمها خبير واحد.

إذا كان هذا الخيار في متناول يدك، فيمكنك استخدامه بانتظام من خلال سؤال أعضاء الفريق لمساعدتك في حل المشكلات الصعبة المرتبطة بالمشروع. بالإضافة إلى تحقيق نتائج جيدة، يسمح هذا النهج أيضًا لأعضاء الفريق بمعرفة أن آرائهم تؤخذ بعين الاعتبار وأنهم يلعبون دورًا مهمًا في المشروع، مما يعزز طاقتهم. النشاط رقم 26 من هو مثال لتطبيق حكمة المجموعة في المشاريع.

قائد المشروع الرائد

إذا كنت مدير مشروع، فإن معظم أنشطتك تيسيريه (أو على الأقل ينبغي أن تكون). من ناحية أخرى، قد تجد أن أعضاء الفريق مروا بتجارب سيئة مع قادة المشروع في الماضي، وأن هذه التجارب لها تأثير على علاقتهم معك: جزء من طاقتهم هو مخصص لتحليل سلوكك لاكتشاف التهديدات المحتملة بدلاً من الوثوق بك. في هذه الحالة، يمكنك تغيير عنوانك من مدير المشروع لقيادة قائد المشروع. بعد كل هذا، هذا ما تفعله بالفعل في المشروع.


يجب ان تكون دائما استباقيا

لدينا ميل طبيعي لنكون مستجيبين. يمكن أن يساعدنا ذلك في الحفاظ على طاقتنا في المجالات الغير مهمة، أو تحقيق نتائج جيدة عندما نعمل في مجال ليس لدينا فيه خبرة. تختلف هذه المواقف عن مشاريعنا، وللحصول على نتائج جيدة هنا، سيكون من الضروري أن تكون سباقا

مثال: تخطيط

إذا كنت ترغب في الوصول إلى مكان لأول مرة وتأخرت، يمكنك البدء في القيادة على الفور “لتوفير الوقت” والتعامل مع المشاكل المحتملة عند حدوثها. تتمثل الطريقة الاستباقية في قضاء بعض الوقت وإعداد “نظام تحديد المواقع العالمي” (GPS) لإعطائك أسرع طريق استنادًا إلى حركة المرور، والأعطال والعوائق المحتملة، ثم الشروع في القيادة؛ وهذا يعني، إعطاء نفسك الوقت للاستعداد قبل التنفيذ، لتجنب المشاكل في وقت لاحق وتوفير الوقت في النهاية.

على عكس ما يعتقد البعض بشأن مشاريع Agile، فإن التخطيط ضروري دائمًا؛ يختلف نوع ومستوى تفاصيل الخطط فقط من منهجية إلى أخرى. التخطيط قبل التنفيذ هو نهج استباقي.

تذكر المثل: “أعطني ست ساعات لقطع الشجرة وسأمضي الأربع ساعات الأولى في شحذ الفأس.”

إذا كان هذا مشروعًا تنبؤيًا ، فيمكنك قضاء 4 ساعات في شحذ الفأس لأنك متأكد من أنك تريد قطع شجرة. في مشروع Agile، لا تعرف ما إذا كنت ستقطع شجرة أو تقوم باستعادة الفروع المكسورة أو حصاد العشب أو استخراج الفحم أو أي شيء آخر. ومع ذلك، يجب أن تكون مستعدا دائمًا بشكل عام (اكتشف أين يقع أقرب متجر ادوات) وبشكل أكثر تحديدًا (شحذ الفأس) عندما تركز على حل معين. هذا هو التخطيط.

مثال: تخطيط المخطط

التخطيط لكيفية تنفيذ المشروع هو نهج استباقي. يمكن تمديد هذا النشاط الاستباقي من خلال تخطيط كيفية تخطيطنا للتنفيذ؛ إنه مفهوم خطة إدارة دليل PMBOK® واستراتيجيات إدارة PRINCE2® ونهج DSDM®.

مثال: تخطيط مستمر

نادراً ما يطابق الواقع توقعاتنا، وهذا أمر متوقع. ومع ذلك، يجب علينا تكييف خططنا باستمرار لضمان بقائها واقعية وعملية. يجب أن نفعل ذلك بمجرد الحاجة إلى التكيف، وليس عندما تنشأ المشكلات؛ هذا هو نهج استباقي.

مثال: إدارة المخاطر

تستند الفكرة الكاملة لإدارة المخاطر على نهج استباقي: في مواجهة الأحداث الغير مؤكدة، فبدلاً من الانتظار لمعرفة ما يحدث والرد عليها، فإننا نفكر في الاحتمالات والآثار، ونفحص الإجابات، ومن الممكن التصرف قبل وقوع الحدث.

لاحظ أن ما نقوم به في المشاريع جدي؛ في بعض الأحيان حياة البشر هي على المحك.

مثال: تحديد الادوار والمسؤوليات

يمكنك اختيار السماح لأعضاء الفريق في المشروع بالعمل دون تحديد أدوارهم ومسؤولياتهم بوضوح. في وقت لاحق، سوف تتضح بعض الادوار والمسؤوليات، لكنها مكلفة للغاية وقد لا تعمل. تتمثل الطريقة الاستباقية في تحديدها مبكرا في المرحلة الأولى من المشروع وملائمتها إذا لزم الأمر. هذا يجعل مهمة الجميع أسهل، ويمكن لأي شخص التركيز على تحقيق الفكرة أو الخدمة أو المنتج، بدلاً من تحديد من يفعل ماذا.

يعتمد عدد الأدوار وتنوعها على نوع وحجم المشروع. يمكن أن يكون تعريفًا بسيطًا مثل Scrum، وهو شيء معتدل مثل أو كامل، مثل تعريف DSDM® وPRINCE2®. ومع ذلك، ضع في اعتبارك أن تعريف الدور في هذه الأساليب ينطبق فقط على أنشطة الإدارة، ولا تزال بحاجة إلى إضافة تعريف الدور للجوانب التقنية.

مثال: الخيارات المتاحة

هل يجب عليك اغلاق المشروع قبل الأوان او الاستمرار فيه؟

لا يوجد نادرا الا خياران، حتى لو كان هذا هو ما يشير إليه السؤال. يجب عليك اتباع نهج استباقي وتحليل جميع خياراتك قبل اتخاذ القرار. ربما يمكنك تغيير مواصفات المشروع؛ ربما يمكنك التوقف حتى يصبح هناك شيء واضح للتطور؛ قد تتمكن من تغيير نهج المشروع (على سبيل المثال، اختيار جهة خارجية لمتابعة المشروع)، إلخ.

مثال: التفكير النقدي

لدينا جميعا احكام مسبقة تساعدنا على البقاء على قيد الحياة من ناحية، واتخاذ قرارات خاطئة من ناحية أخرى. عندما يتعلق الأمر باتخاذ قرارات مهمة بشأن المشروع، فمن الأفضل أن نأخذ الوقت الكافي للنظر في أي احكام مسبقة قد تؤثر على قرارنا قبل أن تصبح مشكلة.

للإشارة، يمكن استخدام قائمة التحيز المعرفي في ويكيبيديا:

هناك حتى أطر عمل لصنع القرار يمكنك استخدامها لتحسين عملية صنع القرار. في البداية، قد يكون الأمر مربكًا أو مزعجًا لاستخدامها، لكنك ستعتاد عليها سريعًا وتطبقها بدون مجهود بمرور الوقت.

مثال: الشفافية

نود أن نتجنب التأخر أو وجود أي مشكلة في المشروع، ولكن هذا لا يعني أننا يجب أن نخفي هذه الحالات إذا حدثت. كن شفافاً وأبلغ أصحاب المصلحة، حيث قد يتمكن بعضهم من مساعدتك. على أي حال، سوف يكتشفون في النهاية المشاكل ونتائجها عاجلاً أم آجلاً، وسيتعين على بعضهم التصرف بسرعة (على سبيل المثال، قبول النتيجة السلبية).

مثال: التواصل بنجاعة

قد تكون هناك العديد من الحالات التي ترسل فيها تقارير إلى أصحاب المصلحة ولا يقدمون لك أي تعليقات. قد تعتقد أن كل شيء على ما يرام لمجرد عدم وجود ردود فعل سلبية، على الرغم من أنه قد لا يكون كذلك. يجب أن تكون استباقيًا وتحقق لمعرفة ما إذا كانوا قد استخدموا بالفعل التقرير وما إذا كان قد خدم هذا الغرض، وجمع كافة الملاحظات لضبط طريقة الاتصال الخاصة بك؛ خلاف ذلك، قد تتسبب هذه المشكلة المخفية في حدوث مشكلات خطيرة لاحقًا، عندما يصعب حلها.

مثال: تحمل المسؤولية

من السهل إلقاء اللوم على الآخرين بسبب النتائج السيئة. على سبيل المثال، قد ترغب في ان تمنحك مؤسستك السلطة الكاملة لتغيير كل شيء في المشروع والقيام بذلك بشكل مثالي، لكنهم لا يفعلون، ونتيجة لذلك، يفشل المشروع. هذا ليس نهج استباقي.

النهج الاستباقي هو تحمل المسؤولية والقيام بكل ما تستطيع ضمن القيود. لا يمكنك أن تتوقع من المنظمة أن تثق بك تمامًا وأن تمنحك كل شيء على أمل الحصول على نتائج جيدة، خاصة عندما يكون هناك الكثير من المشاريع الفاشلة. ما عليك القيام به هو إضافة تحسين صغير ضمن القيود التي تم تعيينها، استخدم ذلك لكسب القليل من الثقة، والمزيد من الموارد والمزيد من التسامح مع القيود، ثم استخدم ذلك للحصول على تأثير إيجابي أكثر وضوحا.


تذكر أن السلسلة قوية فقط مثل أضعف حلقاتها

هناك مجالات مختلفة في المشاريع وكلها تتطلب عناية خاصة. يجب أن يكون لدينا منظور شامل للمشروع. لا يكفي الانتباه إلى مجال يبدو مهمًا (على سبيل المثال، الوقت)، حيث أن جميع المجالات تتفاعل وتعمل بشكل صحيح فقط إذا كانت جميعها تتلقى ما يكفي من الاهتمام.

مثال: كل شيء يعتمد على الموعد النهائي!

دعنا نقول أنك تبني شيئًا للأولمبياد. المواعيد النهائية حاسمة للغاية، مما يجعل إدارة الوقت مهمة للغاية. أليس كذلك؟ ماذا سيحدث إذا كانت جودة العرض سيئة للغاية بحيث تسببت في عمل إضافي للتصحيحات؟ سيكون لها تأثير على الوقت. لذلك الجودة هي بنفس أهمية الوقت. لقد خططت لحديقة متقنة للغاية في التعريف الأصلي للمشروع، لكنك تعلم أنه إذا لم يكن هناك ما يكفي من الوقت، فيمكنك تبسيطه من خلال تغطية سطح العشب، طالما أنك نظرت في هذا الاحتمال في الوقت المناسب وأنك قد أعددت لذلك. وبالتالي فإن إدارة المواصفات مهمة أيضًا. لدينا مجالات المواصفات والوقت والجودة في مركز الاهتمام.

هل سمعت بهذه القصة الشهيرة التي التقى فيها الرئيس كينيدي بواب وكالة ناسا وسأله عما كان يفعله، فأجاب: “أنا أساعد في وضع رجل على سطح القمر”؟ هل تساعد مشاركة هذا النوع من الأشخاص في احترام المواعيد النهائية؟

مع تقدمك، ستجد أن كل مجال من مجالات المشروع يساهم في إدارة الوقت، ولا يمكنك احترام الموعد النهائي مع اليقين المقبول إذا لم تهتم بجميع المجالات.

مثال: قطف الكرز

عندما نتعرض لمنهجيات مختلفة، نبدأ في بعض الأحيان في اختيار العناصر من كلا الجانبين وإنشاء مزيج من كل شيء يبدو مثيراً للاهتمام من أنظمة مختلفة. هذا عادة لا يعمل لأن العناصر لا تعمل بمعزل ويجب أن تكون متوافقة مع بعضها البعض. يجب إجراء أي إضافات أو تغييرات على نظام بطريقة شمولية.

لهذا السبب نلاحظ أحيانًا عناصر متناقضة في منهجيات مختلفة؛ شيء يعمل جيدا في نظام واحد، والعكس يعمل بشكل جيد في النظام الآخر. هذا العنصر ليس صحيحًا أو خاطئًا في حد ذاته.

تتمثل الطريقة الأكثر أمانًا في تحديد منهجية للمشروع، وتكييفه، ثم إضافة عناصر جديدة بحذر مع مراعاة تماسك النظام بأكمله.

مثال: Anti-Processus

أحد أهم الأشياء التي قامت بها منهجيات Agile هو لفت الانتباه إلى الجوانب الإنسانية. يبدو أن بيان Agile يعطي قيمة أكبر للبشر من العمليات والأدوات. لاحظ أن هذا البيان غير دقيق لأن جميع المنهجيات تقول إن الجوانب البشرية مهمة، والفرق الحقيقي مع منهجيات Agile هو أن الجوانب البشرية جزء لا يتجزأ من عملياتها، وليس مجرد اقتراح. لذلك فهي ليست منافسة بين الجوانب البشرية والعمليات، ولكنها تركز بشكل خاص على كيفية التعامل مع الجوانب البشرية في النظام.

ليس هناك شك في أن بعض الناس يحاولون استبدال الجوانب الإنسانية بعمليات أكثر تطوراً، ولكن هذه مجرد ممارسة سيئة. يوجد العكس أيضًا: الأشخاص الذين يحاولون استبدال العمليات بالجوانب البشرية، والتي لا تعمل جيدًا أيضًا.

مثال: هذه هي جميع المجالات التي تحتاج إليها

عند التفكير في المجالات، احرص على عدم إغفال أي شيء. ولكن ما هي المجالات؟ إذا قمت بالتحقق من قواعد المعرفة الأساسية، فستحصل على إجابات مختلفة، ولكن لا أحد منهم هو الحقيقة الكاملة.

تعد محاور PRINCE2® مجالات، لكن هذه فقط المجالات التي تلعب دورًا رئيسيًا في المنهجية. المجالات الأخرى هي ضمنية فقط.

دليل PMBOK® ليس منهجية ويمكن صياغته بشكل أفضل مع مجالات المعرفة العشرة. ومع ذلك، فهذه تفسيرات لجميع المجالات استنادًا إلى منظور PMBOK® Guide في المشروع، بدلاً من منظور محايد (وليس بالضرورة أن يكون هناك منظور محايد). على سبيل المثال، لا تحظى الجوانب البشرية باهتمام كبير في دليل PMBOK®.

مصدر جيد للمعلومات حول المجالات هو ICB. ومع ذلك، لا يتعلق الأمر بالمجالات، بل يتعلق بالكفاءات المطلوبة في المشروع. ليس لها علاقة فردية بالمجالات، ولكنها تساعد كثيرًا في تحديدها.

لا توجد قائمة بالمجالات في NUPP، وذلك أساسًا لأنه نظام تعريف بدلاً من نظام، وأيضًا لأن تصنيف المجالات يعتمد على نوع المشروع وبيئته؛ على سبيل المثال، قد يحتاج مشروع البناء الروتيني إلى منظور مختلف عن مشروع بحث إبداعي.


لا تقم باي شيء بدون هدف واضح

يجب ألا تفعل أي شيء ما لم يكن له هدف واضح. تخيل عالمين متوازيين حيث كل شيء هو نفسه باستثناء الشيء الذي تفكر في القيام به: ما مدى اختلاف هذه العوالم؟ هل الفرق يستحق الجهد للقيام بهذا الشيء؟

إذا لم يكن لديك هدف واضح وفعلت شيئًا فقط لأن أي شخص آخر يقوم بذلك، أو يقول الجميع إنه من المهم القيام بذلك، فعندئذ:

  • قضيتك قد لا يكون لها فائدة حقيقية، ولايمكنك الحصول على أي شيء منها، او
  • قد تظل لها فوائد محتملة في قضيتك، ولكن نظرا لأنك لا تضع الهدف في الاعتبار، فقد لا تساعد طريقتك في تحقيق الأهداف.

مثال: الملفات والبرامج

إذا كنت مشتركًا في اختيار المشاريع وإطلاقها، فيجب عليك التركيز على الفوائد والمشاكل التي من المفترض حلها بدلا من المنتج الذي سيقوم بهذه الأشياء. المثال الكلاسيكي هو مثال المصنّع الذي اعتاد على تلقي شكاوى حول سرعة المصاعد الخاصة به والذي أطلق عدة مشاريع لزيادة سرعة المصاعد دون نجاح. استمر هذا الوضع حتى قرروا التركيز على المشكلة (الملل او انزعاج الناس) بدلاً من الحل “الطبيعي” (المصاعد الأسرع). نتيجة لذلك، أضافوا المرايا إلى المصاعد، والتي ببساطة حلت المشكلة.

تذكر أن إدارة المشروع تدور حول القيام بالعمل بشكل صحيح، في حين أن إدارة الملفات تدور حول اتخاذ الخيارات الصحيحة. بغض النظر عن مدى جودة إدارة مشاريعك، فلن تعمل إذا اخترت المشاريع الخاطئة. يجب ان يكون هناك هدف.

مثال: المشروع ككل

تختلف مرونة المنتج حسب المشروع. في بعض مشاريع تطوير تكنولوجيا المعلومات، يكون المنتج مرنًا تمامًا ويعتمد شكله النهائي على الملاحظات الناتجة عن الزيادات في المنتج أثناء المشروع، مما يتطلب اتباع نهج تكيفي (Agile). إنه عملياً مزيج من طبقات الملفات، البرنامج والمشاريع، وينبغي إيلاء أقصى درجات الاهتمام للهدف النهائي. من المستحسن توثيق الهدف وجعله في متناول اليد؛ هذا هو أحد أهداف “رؤية المنتج” المستخدمة في بعض أنواع المشاريع مثل مشاريع Scrum. الانتباه إلى القيمة التجارية في مشاريع Agile هي وسائل مواكبة لهدفهم.

في أنواع المشاريع الأخرى، حيث يكون المنتج ثابتًا نسبيًا وهناك آليات أخرى لضمان أن المنتج المحدد يفي بالهدف المرغوب فيه، يمكن لأعضاء فريق المشروع تحويل الكثير من تركيزهم من الهدف إلى المنتج (ومن هنا المبدأ “التركيز على المنتج” في PRINCE2®)، ولكن يلزم الحد الأدنى من الاهتمام للمنتج لتحقيق هذا الهدف، والذي يمكن أن يتحقق بالقيام بمقارنة بين الفوائد المحتملة والفوائد المتوقعة (وبالتالي مبدأ “التبرير المستمر للأعمال” وموضوع “حالة العمل” في PRINCE2®).

عندما يتم تنفيذ المشروع للعملاء الخارجيين، يكون للعميل هدفه الخاص ولعملك غرض مختلف. يجب أن تفهم وتستخدم كلا الهدفين لتحقيق النجاح حقا.

مثال: مراقبة المشروع

من الضروري التركيز على الهدف النهائي، ولكنه قد يكون مجرّدًا للغاية للعديد من الاستخدامات اليومية. لهذا السبب هناك حاجة إلى تسلسل هرمي للمؤشرات لجعله عمليا أكثر. أولاً، يتم تحديد مبررات المشروع وفوائده استنادًا إلى الهدف النهائي، وبعد ذلك سيكون لديك أهداف صريحة وضمنية لمتغيرات المشروع (على سبيل المثال، الوقت والتكلفة والجودة) لتلبية هذا المبرر، والذي بدوره سوف يفي بالهدف النهائي. هذه هي أهداف المستوى الأدنى التي تكون مفيدة لكثير من مهامنا اليومية.

عندما يتعلق الأمر بالمتابعة، سيتم إجراء مراقبة منخفضة المستوى للمشروع باستخدام أدنى مستوى للمتغيرات، لأنه قد لا يكون من الممكن تتبع الهدف النهائي. في هذه الحالة، يجب أن تظل لديك الأغراض في الاعتبار: ما هو الغرض من المراقبة؟

الإجابة العادية والمقبولة هي معرفة ما إذا كنا على المسار الصحيح، وإذا لم يكن الأمر كذلك، لإثارة رد فعل معين سيعيدنا إلى المسار الصحيح أو يعدل الأهداف ونرى ما إذا كان لا يزال بإمكاننا تحقيق الهدف النهائي. لذلك ينبغي أن تكون قياساتنا قادرة على المساعدة في تحقيق هذا الغرض المنخفض المستوى، والقياسات المناسبة هي توقعات للمتغيرات عند الانتهاء؛ على سبيل المثال، متى سنكون قادرين على إنهاء المشروع؟ كم من المال سنحتاجه لإنهاء المشروع؟

جميع القياسات الأخرى، مثل القيم المخططة والفعلية حتى الآن، هي مجرد قيم مؤقتة نحتاجها من أجل حساب التوقعات، وليست القيم النهائية التي نستخدمها لأغراض إدارية.

مثال: الوثائق

بغض النظر عن نهج التطوير الذي تستخدمه في المشروع، فإن التخطيط ضروري دائمًا. السؤال المهم هو مستوى التفاصيل في كل نوع من الخطة. إذا لم تكن هناك تفاصيل كافية في الخطة، فلن تكون الخطة قادرة على المساهمة بما فيه الكفاية، وسوف يعتمد تنفيذ المشروع على قرارات مخصصة بدلاً من القرارات المتكاملة والشاملة. من ناحية أخرى، يحاول الكثير من الناس أن يكونوا حذرين وأن يضيفوا الكثير من التفاصيل إلى خطتهم، مما يجعل من الصعب للغاية الإعداد والمحافظة عليها، وقاسية للغاية فيما يتعلق بأوجه عدم اليقين في المشروع. نتيجة لذلك، تصبح الخطة غير واقعية وغير مجدية.

أفضل طريقة لتحديد مستوى التفاصيل هي وضع هدف في الاعتبار لكل عنصر في الخطة. على سبيل المثال، إذا كنت تفكر في إضافة موارد للخطة، فيجب أن يكون لديك غرض منها: كيف ستستخدمها؟ كيف سيساعد المشروع؟ كم من الجهد سيستغرق؟ وهل هو يستحق كل هذا العناء؟

يتعلق الأمر أحيانًا بتحديد ما إذا كنت تريد أن يكون لديك عنصر معين في خططك، وفي بعض الأحيان عن الطريقة التي تريد أن تخطط لها أو تعد شيئًا ما. سواء أكان الأمر يتعلق بحالة تجارية أو ميثاق مشروع أو تقرير: يجب أن تسأل نفسك دائما عن سبب تحضير هذا المستند وكيف يمكن أن يساعد المشروع.

البحث عن “نسخة” هو عكس فعل شيء بناءً على الغرض.

مثال: تقرير عن وضعية المشروع

من الشائع أن يكون لديك تقارير وضعية طويلة جدًا في العديد من المشاريع. استنادًا إلى هذه القواعد العامة تقريبا (NUP)، يجب أن نسأل أنفسنا ما هو الغرض من التقرير وكيف يمكننا تحقيق هذا الهدف، بغض النظر عما يمكن لمعظم الناس فعله.

يمكن أن يقودنا هذا في العديد من الحالات إلى إعداد تقارير بسيطة للغاية من صفحة واحدة يقرأها أصحاب المصلحة ويفهمونها حقًا بدلاً من التقارير الطويلة. يساعد هذا أيضا على الانتباه الى الهدف.

ومع ذلك، إذا كنت تعد تقارير من صفحة واحدة، فقد يعترض بعض الأشخاص ويعتقدون أنه ليس لديك نظام متابعة “مناسب”. يؤدي هذا في الأساس إلى إنشاء هدف ثانٍ لك (بالإضافة إلى الهدف الأول، وهو مساعدة أصحاب المصلحة على فهم حالة المشروع) ولتحقيق ذلك، يمكنك ببساطة إنشاء نوع ثانٍ من التقارير الطويلة جدًا. ومع ذلك، فلن تجمع هذا مع التقرير الأول لأن هذين الهدفين ليسا متماثلين.

مثال: دراسات العمل وميثاق المشروع

يعد إعداد مستندات مثل دراسة العمل وميثاق المشروع ضرورة شاقة وغير ناجحة وبيروقراطية لمعظم الأشخاص، في حين أن هذه المستندات جميعها لها أهداف صالحة تنطبق على معظم المشاريع. إذا كنت تحاول العثور على “قالب” وملئه، فإن العمل ببساطة لا فائدة منه، في حين يمكنك بدلاً من ذلك التحقق من الغرض الحقيقي من هذه المستندات، ومعرفة كيف وما إذا كانت يمكن أن تكون مفيدة في مشروعك، ثم قم بإعداد المستند كما تريد، فقط لتحقيق هذه الأهداف: إنها الوثيقة الصحيحة.

عند التفكير في كيفية إعداد المستندات لتحقيق أهدافها، لا يمكنك التفكير في جميع السيناريوهات وقد تفوتك بعض التفاصيل. لتجنب ذلك، يمكنك التحقق مما يقترحه PRINCE2® وPMBOK® Guide و وDSDM®، ثم تقييم هذه الاقتراحات بناءً على أهدافك.

مثال: ما بعد المشروع

على الرغم من أن المشروع له هدف محدد ويمكن أن نأخذه في الاعتبار في جميع مراحل المشروع، إلا أن تحقيقه يتم تقييمه بشكل أساسي على أساس التوقعات التي تم إجراؤها أثناء المشروع، ويجب ألا ننسى ذلك بمجرد الانتهاء من المشروع. من المهم التحقق من تحقيق الأهداف بمجرد اكتمال المشروع للأسباب التالية:

  • يمكننا أن نرى كيف يتم تحقيق الأهداف النهائية والتعلم منها لمشاريع المستقبل، و

  • في بعض الأحيان لا تتحقق الأهداف إلا إذا قمنا ببعض الأعمال الإضافية بعد الانتهاء من المشروع، وفهم الحاجة إلى هذه المهام الإضافية يتطلب المتابعة.

تعتبر مراقبة ما بعد المشروع خطوة ضرورية إذا كنت موجهة نحو الهدف. هذه هي مسؤولية أنظمة إدارة البرامج بشكل أساسي، وبما أن معظم الشركات لا تملك هذه المستويات الإدارية، يتم تجاهل هذه الخطوة عادة. لهذا السبب تضيف وDSDM® هذه الخطوة إلى منهجيات إدارة المشاريع.

مثال: البساطة

العالم معقد وفوضوي، لكن نماذجنا تقريبية مجردة تعكس أجزاء من العالم، وبالتالي يمكن أن تكون بسيطة. من ناحية أخرى، عادة ما تعمل الأنظمة البسيطة بشكل أفضل، لأنه يمكننا التركيز على الفكرة الرئيسية.

يحاول الكثيرون منا الحصول على نتائج أفضل من خلال إضافة التعقيد إلى أنظمتنا، على أمل أن يتطابق ذلك مع تعقيد العالم، على الرغم من أن هذا الأمر يجعل من الصعب في الواقع على النظام العمل ويمنعنا عادة من تحقيق الغرض.

مثال: الملائمة

المشاريع ليست متشابهة. يفرض برنامج تسليم الموسيقى عبر الإنترنت شروطًا مختلفة تمامًا عن تلك التي يتم استخدامها لتجهيزات مستشفى أو لطائرة قد تعتمد حياتنا عليها، أو برنامج يتم استخدامه في قمر صناعي حيث من المفترض أن يعمل لسنوات عديدة دون ان يتعطل، وهذه البرامج كلها تختلف عن بناء منزل عطلة، ومحطة إطفاء ومصنع للمعالجة.

بمجرد وضع الأهداف في الاعتبار، ستفهم بشكل أفضل كيفية ملائمة الانظمة والوثائق مع مشاريع مختلفة.


استخدام العناصر القابلة للتكرار

يتطلب النهج المخصص للمشروع الكثير من الطاقة والموارد، ويواجه دائمًا خطر فقدان بعض العناصر الضرورية. أفضل طريقة لتبسيط ما يجب القيام به هي استخدام العناصر القابلة للتكرار، ويفضل أخذها في دورات قابلة للتكرار.

مثال: قوائم مراجعة الجودة

القائمة هي مثال بسيط لعنصر يمكن تكراره يستخدمه كثير من الناس في حياتهم الشخصية والمهنية. خذ على سبيل المثال معايير الجودة للتسليم:

  • أولاً، يمكنك إنشاء قائمة بجميع المعايير، وهي شكل من أشكال التخطيط.
  • يوصي المبدأ NUP6 بتوحيد القائمة: هل هناك تسليمات مماثلة في المشروع؟ في هذه الحالة، قم بإعداد قائمة تحقق الجودة العامة لهذه الفئة من التسليمات واستخدامها لكل منها. إذا كانت المتغيرات موجودة، احتفظ بهذه القائمة وأضف بعض العناصر الإضافية للنواتج الفردية. الآن لديك قوائم مرجعية قابلة للتكرار.
  • عندما تقوم بإعداد قوائم تدقيق عامة لأنواع مختلفة من التسليمات، يمكنك العثور على عناصر مكررة، مما يشير إلى إمكانية إنشاء فئة رئيسية افتراضية لها. في هذه الحالة، بدلاً من تكرار عناصر كل هذه القوائم العامة، قم باستخراجها ووضعها في قائمة أم. أخيرًا، سيكون لديك على الأرجح قائمة عامة للمشروع بأكمله. تعتبر معايير القبول Scrum مثالاً على قائمة مراجعة الجودة (من بين أمور أخرى) على مستوى المشروع. عند القيام بذلك، سينتمي كل ناتج إلى تسلسل هرمي للفئات وسيتعين عليه إرضاء العناصر التي تظهر في قوائم جميع فئات سلسلتهم.

وبالتالي، يصبح عنصر من عناصر القائمة الأم مستنسخة لجميع المهام الفرعية، مما يوفر الوقت والطاقة في التخطيط والتنفيذ. علاوة على ذلك، بمجرد استغلاله لمشروع، يمكنك ملائمته واستخدامه لجميع المشاريع المماثلة في المستقبل، وهو شكل للتخطيط قابل للتكرار لعدة مشاريع.

مثال: العمليات وسير العمل

بعض النواتج، أو الأهداف المرتبطة بها، تحتاج إلى خطوات معينة يمكن أن تصبح موحدة وقابلة للتكرار. على سبيل المثال، إذا كانت النواتج بحاجة إلى تصميم فردي واعتمادها، فيمكنك إعداد سير عمل بسيط يجعل جميع الخطوات والأشخاص المعنيين والمدد التقريبية واضحة، وبالتالي تجنب العديد من الصعوبات. ومع ذلك، يجب أن تكون حريصًا على عدم جعل مهام سير العمل والعمليات معقدة للغاية أو مكثفة للغاية في الوثائق، حيث ستكون لها عواقب سلبية. يجب على جميع المشاركين في المشروع أن ينظروا إلى سير العمل والعمليات على أنه شيء يدعم عملهم ويجعل كل شيء أسهل لهم، بدلاً من التوثيق البيروقراطي الذي يمنع عملهم الحقيقي.

تحتوي المشروعات Agiles على عناصر قابلة للتكرار في نهج التطوير التكراري الخاص بها، حيث يتم تكرار نوع معين من أنشطة التطوير لكل وظيفة؛ مثلا الروتين اليومي الشائع في XP (eXtreme Programming): الإقران، واختيار عنصر، تصميمه على لوحة بيضاء، وإنشاء نصوص برمجية للاختبار، ودمج الرمز، إلخ.

بجانب مهام سير العمل القابلة للتكرار التي يمكن استخدامها في الأنشطة الفنية، يمكنك أيضًا إنشاء عناصر قابلة للتكرار لأنشطة إدارة المشروع. تعتبر العمليات في PMBOK® Guide وPRINCE2® وDSDM® والأنشطة في والأحداث في Scrum هي أمثلة على هذا المفهوم.

مثال: الدورات

وجود عناصر قابلة للتكرار لإدارة المشروع أمر مفيد. يمكن جعل هذا أسهل عن طريق وضعها في دورات قابلة للتكرار. تعمل هذه الدورات على تبسيط الأنشطة اليومية للمشاركين في إدارة المشروع وتوجيهه. دورات مجموعة العملية في دليل PMBOK® المستخدم في مشروع متعدد المراحل، خطوات في PRINCE2®، دورات يومية وأسبوعية وشهرية في، التكرارات وTimeboxes في DSDM® وSprints في Scrum هي أمثلة على هذا المفهوم.

الدورات القصيرة هي أسهل في الفهم والاستخدام من الدورات الطويلة؛ على سبيل المثال، تختلف Sprints in Scrum عن المراحل وفقًا لدليل PMBOK®. ومع ذلك، قد لا تكون الدورات القصيرة جدًا كافية لدعم أنواع معينة من المشاريع. قد يكون الحل هو استخدام عدة دورات، مثل استخدام DSDM® لدورات timebox القصيرة ذات دورات التكرار الأطول، أو استخدام في الدورات اليومية والأسبوعية والشهرية.

مثال: الأساليب

يعد استخدام منهجية أو إطار عمل لتنفيذ مشروع مثالًا آخر على استخدام العناصر القابلة للتكرار. قد تكون منهجية حالية مثل PRINCE2® أو أو DSDM® أو Scrum أو نظام قمت بتخصيصه أو بنائه بنفسك. ومع ذلك، من الأفضل عادة البدء بإحدى المنهجيات الحالية وتكييفها حسب احتياجاتك بدلاً من بناء طريقة جديدة.

أي عنصر قابل للتكرار هو تجريدي ويحتاج إلى التخصيص ليتكيف مع العالم الحقيقي. هناك طيف من التجريد والحاجة إلى التخصيص، على الرغم من ذلك: قوائم تدقيق الجودة القصيرة والدقيقة نسبياً تقع في نهاية الطيف مع الحد الأدنى من التجريد واحتياجات الملائمة، في حين أن المنهجيات هي في الطرف الآخر، مع الحاجة القصوى للتكيف. يجب عليك دائمًا ملاحظة الحاجة إلى التكيف، وإلا فلن يناسب العنصر القابل للتكرار احتياجاتك.


“NUPP” je skraćenica od „Nearly Universal Principles of Projects“ tj. označava zbir “skoro univerzalnih principa projekata”: onih koje bi bilo dobro slediti u svim projektaim, bez obzira na metodologije i pristupe koje u njima upotrebljavamo, kako bi postigli maksimalni uspeh.

Svaki od raspoloživih resursa i metoda za sprovođenje projekata počiva na NEKIM od ovih “NUP”-ova (skoro univerzalnih principa). Ipak, sledeće stvari treba imati na umu:

  • “Počiva na NEKIM” (podvučeno u prethodnom pasusu): obično ne na SVIM, a praktičarima projektanog menadžmenta se upravo preporučuje da uzmu u obzir SVE “NUP”ove, a ne samo neke od njih.
  • U resursima i metodima ovi principi (na kojima se zasnivaju) nisu dovoljno očigledni, pa kako je većina praktičara prečesto fokusirana na praktične detalje, zaboravlja na principe i radi stvari u neskladu sa njima.

“NUP”ovi su kompatibilni sa svim važnim metodima, sistemima, resursima i framework-ovima kao što su: PRINCE2®, PMBOK® Guide,, PM², DSDM®, XP, and Scrum. Doduše, može se desiti da nisu kompatibilni sa određenim interpretacijama ovih sistema, i upravo u tim slučajevima “NUP”ovi treba da ohrabre praktičare da preispitaju te interpretacije.

“NUPP” je zbir sledećih “NUP”ova:


Rezultati i istina pre pripadnosti

Svi mi imamo prirodnu tendenciju da pripadamo grupama, tendenciju koja često prevazilazi svoju osnovnu formu, kreirajući snažne veze koje mogu izazvati i probleme. Može se čak desiti da izgubimo mnogo više zbog tih veza nego što dobijemo u određenim situacijama. Ne trgujmo sopstvenim profesionalnim integritetom, identitetom i sklonostima, za račun pripadnosti određenoj grupi.

Primer: Agile vs waterfall

Grupa izuzetnih entuzijasta koja je bila dovoljno hrabra da koristi adaptivne pristupe razvoju unutar IT razvoja, u vreme kada se dominantno koristio prediktivni pristup, okupila se i nazvala svoj pristup “Agile”. Ovo je bila sjajna inicijativa da se izbegne ograničavanje izbora samo na ono što se činilo neophodnim. Još uvek je puno entuzijasta usmerenih na rezultat u Agile zajednici, nažalost u njoj ima i nekih koji teže da Agile pretvore u kult, posmatrajući sve van nje u neprijatelje. Ovo stvara višestruke probleme, uključujući i sledeće:

  • Sprečava ih da uče od bilo koga van grupe
  • Obeshrabruje one van grupe da uče od njih
  • Stavlja pripadnost grupi ispred stvarne svrhe, što kao rezulat sprečava pripadnike grupe da nauče o stvarnom smislu „Agilnosti“

Ovaj problem se može značajno umanjiti (ako ne i otkloniti), upotrebom reči “Agile” SAMO kao oznake koja se odnosi na razvojni pristup, a ne na zajednicu sa svojim članovima; dalje, uz pomoć LJUDI koji smatraju sebe kreatorima, rešavaocima problema, i liderima kojii vide “Agile” jednostavno kao JEDAN OD SVOJIH ALATA, A NE KAO SVOJ IDENTITET.

Za prave profesionalce ne postoji rat “Agile” protiv “Waterfall”-a!

Primer: PRINCE2® vs PMBOK® Guide

Mnogi profesionalci u projekt menadžment zajednici se identifikuju ili sa PRINCE2® metodologijom ili sa PMBOK® framework-om (često samo zbog geografske lokacije) i nisu upoznati sa drugom stranom. Svi mi možemo naginjati određenim resursima, ali ne dovodeći svoj profesionalni identitet i integritet u pitanje. Još važnije, trebalo bi da se familijarizujemo sva svima njima šireći svoje vidike i mogućnosti izbora.

Pravi profesionalci su otvoreni za sve ideje, tražeći ih, učeći o njima, i koristeći ih kada je potrebno, bez stvaranja nekritičke pripadnosti tj. vezivanja za iste.

Primer: Neprekidno učenje

Vezivanja za određene ideje ili zajednice, zadovoljavaju osobu zbog pratećeg osećaja pripadnosti, ali je ne podstiču da uči, ponekad čak i obeshrabruju zbog straha od gubitka te iste pripadnosti. Ako je osoba slobodna, ako je ekspert sa integritetom ispred pripadnosti, stalno će popunjavati praznine u svom shvatanju učenjem: neprekidnim učenjem.

ONO U ŠTA DANAS VERUJEMO NIJE POTPUNA ISTINA (VEĆ VIŠE NAŠE TRENUTNO RAZUMEVANJE KOJE TREBA PRODUBITI), A SUTRA VEĆ MOŽE BITI POLUISTINA. Ako su nečije ideje godinama fiksirane bez ikakvih promena, onda sa njima nešto nije redu. Ovo je slučaj i za NUPP: ako se vratiš ovde za nekoliko godina i vidiš potpuno isti sadržaj, treba da budeš sumnjičav.

Primer: Otvorenost

Kada polemišeš ili prigovaraš, budi siguran da ciljaš na ideju a ne na osobu. Ovo će pomoći da se smanje tenzije. Slično tome, kada nego polemiše sa tobom ili ti prigovara, ne shvataj to kao rat protiv tebe, već kao diskusiju o tvojim idejama i ostani otvoren za primanje. Ne slušaj da bi odgovorio, slušaj da bi razumeo; radi sa tom osobom na poboljšanju ideje.

Neki ljudi će možda namerno “gađati” tvoju ličnost umesto ideje, u kom slučaju treba da im pomogneš da se fokusiraju na ideju umesto na tebe pre nastavka diskusije. Pokušaj da ovo održavaš i u nastavku diskusije.


Očuvaj i optimizuj energiju i resurse

Resursi su ograničeni. Resursi raspoloživi projektu su ograničeni, baš kao i mentalna energija koju imaš za donošenje dobrih odluka. Treba da očuvaš i optimizuješ ovaj resurs za sebe i projekat, kao i da pomogneš drugim članovima tima da urade isto.

Primer: Pravilo 80/20 (Paretovo pravilo)

Najveći deo potencijalnih benefita (recimo 80%) od projeknog menadžmenta dobija se trošenjem manjeg dela (recimo 20%) od ukupno planiranog napora potrebnog za dostizanje 100% benefita. U većini slučajeva, ciljajući 100% mogućih benefita je skupo i neopravdano. Treba slediti ovo pravilo u svemu što radite i ohrabriti druge da isto tako rade.

Primer: Zamorenost odlučivanjem

Mi koristimo jedan izvor mentalne energije za sve vrste odlučivanja, kao i da izrazimo snagu volje. Ako ovu energiju trošiš na manje važne ili nebitne odluke, imaćeš manje energije za važne odluke, što može dovesti do loših rezultata. Ovo je jedan od razloga zašto treba izbeći “mikro-menadžment” (“upravljaj prema izuzetku” princip PRINCE2®).

Konflikti koji nastaju oko ideja, mogu da budu korisni, ali oni koji nastaju oko/zbog ljudi obično štete projektu, a jedna od posledica je „ceđenje“ mentalne energije članova tima. Ako primetiš takav konflikt, daj sve od sebe da nađeš glavni uzrok i rešiš ga.

Primer: Pobrini se za sebe !

Odluke koje donosiš i snaga volje koju izražavaš koriste tvoj izvor mentalne energije. Sa druge strane, ovaj izvor se dopunjava kada redovno spavaš i pravilno se hraniš. Dakle, potrudi se oko sebe : spavaj i odmaraj dovoljno, hrani se dobro i pravilno. Ako imaš štetne navike ili probleme sa spavanjem, ne prepuštaj se sam sebi ; postoje specijalisti koji ti mogu pomoći. Fizička aktivnost takođe pomaže sa ovim izvorom energije, iako istraživanja po ovom pitanju nisu jednoglasna.

Ohrabri članove tima da urade isto što i ti. Prvo, osiguraj da rade održivim tempom i bez mnogo prekovremenog rada. Zatim, ako imaš tu vrstu mogućnosti, ponudi im energetsku, zdravu hranu i piće tokom radnog vremena.

Primer: Ravnoteža između privatnog i poslovnog

Mnogi od nas vole ono što rade, ali to još uvek nije sve što im treba u životu. Na isti način na koji optimizuješ svoj posao treba da planiraš i sprovodiš ideje u svom privatnom životu, tako da ti donose radost i sreću. Kada si srećniji, tada si i uspešniji u poslu. Ohrabruj članove tima da rade isto.

Primer: Motivacija

Motivacija je kompleksan koncept. Postoje neki jako interesantni i korisni resursi na ovu temu, ali još mnogo više ne-naučno zasnovnih. Ipak, treba da naučiš o njima I neprekidno ih koristiš, jer time povećavaš mentalnu energiju tima I mogućnost postizanja boljih rezultata projektaa.

Sredstva za motivaciju mogu biti veoma jednostavna: daj ljudima na znanje da prepoznaješ njihov dobar rad, ljubaznim osmehom ili jednostavnim “Hvala Ti!”. Oprez: mnoge česta sredstva za motivaciju, kao što su male novčane nagrade, mogu imati i negativan efekat.

Primer: Saradnja i timski rad

Ljudi koji sarađuju mogu nekada imati moć da poboljšaju rezultate, ali ono što je još važnije, ljudi su društvena bića i vole da su deo grupe. Ako im ukloniš negativne aspekte timskog rada i napraviš prijatno okruženje, imaćeš srećnije članove tima u projektu.

Oprez: ljudi su različiti, tako da je nekima potrebnije opušteno, fokusirano i samostalno vreme, nego drugima – ovde govorimo o balansiranju potreba unutar tima.

Primer: Kultura “jedan-tim”

Postoji tendencija da različiti pojedinci ili interesne grupe (stakeholders) stvaraju ili podržavaju “klanove” i stvaranje tenzija unutar grupe ili sa drugim grupama; na primer, “ljudi fokusirani na poslovni aspekt” naspram “ljudi koji prave projektani proizvod”. Ovakva tenzija može “ukrasti” puno energije obeju strana, i to je razlog više da radimo na tome da napravimo kulturu “jednog-tima” gde svi rade ka istom cilju bez obzira na ulogu unutar projektaa.

Primer: Mudrost grupe

Ako se skupi na jednom mestu veći broj ljudi različitih profila da radi u moderiranom okruženju (sastanak, radionica, prezentacija, konferencija…), ovde postoji potencijal za stvaranje jako dobrih rezultata, ideja, rešenja, čak i boljih nego ona koja dolaze od pojedinačnih eksperata.

Ako imaš ovu mogućnost, koristi je redovno da zamoliš članove tima da ti pomognu u rešavanju složenih projektanih problema. Osim dobijanja dobrih rezultata, druga prednost je što time stavljaš na znanje članovima tima koliko ceniš njihovo mišljenje i da imaju važnu ulogu u projektu, što sa druge strane podiže njihov nivo energije i raspoloženja. Aktivnost #26 u je primer korišćenja “mudrosti grupe” u projektaima.

Primer: Glavni projektani moderator

Ako si projektani menadžer, većina stvari koje radiš ima prirodu moderacije (ili bi trebalo da ima). Sa druge strane, možda primetiš da su članovi tima u prošlosti imali loša iskustva sa projektanim menadžerima, i da projektuju ta iskustva na sadašnju situaciju. To može uticati značajno na vaš odnos:oni troše značajan deo energije analizirajući tvoje ponašanje, tražeći potencijalne pretnje umesto da ti veruju. U tom slučaju, promeni svoj naziv od “projekt menadžera” u “glavnog projektanog moderatora”. Na kraju krajeva, to je ono što stvarno radiš u projektu.


Uvek budi proaktivan

Postoji prirodna tendencija u nama da budemo reaktivni. To nam pomaže da očuvamo energiju izbegavajući bavljenje nevažnim stvarima, ili dati bolje rezultate u situaciji kada se suočimo sa nečim gde smo potpuno nekompetentni. Ove situacije se razlikuju od projekata, gde proaktivnošću postižemo mnogo bolje rezultate.

Primer: Planiranje

Ako voziš na neku novu lokaciju, a pri tome kasniš, započećeš vožnju ODMAH BEZ PRIPREME kako bi “uštedeo vreme” i usput ćeš se hvatati ukoštac sa eventuanim problemima, onako kako nastaju, improvizujući. Proaktivni pristup bi bio: uzeti neko vreme pre početka vožnje, podesiti navigacioni sistem da ti da najbržu rutu zasnovanu na gustini saobraćaja, mogućim incidentima i blokadama duž puta, PA TEK ONDA započeti vožnju; to znači provesti neko vreme pre IZVRŠENJA putovanja, da bi izbegao kasnije probleme, i samim tim došao do kraja uz uštedu vremena.

Nasuprot tome šta neki ljudi misle o Agile projektaima, PLANIRANJE JE UVEK NEOPHODNO, radi se samo tipu i nivou detalja u planovima. PLANIRANJE PRE IZVRŠENJA JE PROAKTIVNI PRISTUP.

Seti se citata: “Ako mi daš 6 sati da isečem celo drvo, prvih sat vremena provešću u oštrenju sekire”.

Ako je Prediktivan projekat u pitanju, možeš da provedeš i 4 sata oštreći sekiru, ako si unapred siguran da je cilj iseći celo drvo. U Agilnom projektu, nisi unapred siguran da li ćeš seći drvo, skupljati razbijene grane, ostatke od žetve, kopati ugalj iz rudnika, ili nešto drugo. Pa ipak, još uvek moraš da obaviš generalnu pripremu za sve to (da znaš gde je najbliža prodavnica alata), nešto specijalne pripreme (oštrenje) kada se budeš fokusirao na određeno rešenje – to se zove planiranje!

Primer: Planiranje planiranja

Planiranje načina na koji ćemo izvršiti projekat je proaktivan pristup. Ova proaktivnost se čak može proširit planiranjem načina na koji ćemo da planiramo izvršenje; to su npr. Sledeći koncepti: “projekt menadžment plana” kod PMBOK® Guide, menadžment strategija PRINCE2®, i pristupa kod DSDM®.

Primer: Neprekidno planiranje

Realnost se retko poklapa sa onim što smo planirali, i to je OK – ali, moramo neprekidno da prilagođavamo naše planove kako bi bili sigurni da ostaju realistični i praktični. To treba uraditi odmah čim procenimo da je prilagođavanje neophodno, a ne tek onda kada uletimo u probleme. TO JE PROAKTIVNI PRISTUP.

Primer: Upravljanje rizicima

Ceo koncept risk menadžment se zasniva na proaktivnosti: kada smo suočeni sa neizvesnim događajima, umesto da čekamo i gledamo šta će se desiti i tek onda regujemo na njih, mi već unapred mislimo na VEROVATNOĆU I UTICAJE ovih neizvesnih događaja, razmatramo odgovore na njih, i na kraju i uradimo nešto unapred, kako bi ih predupredili.

Obratite pažnju da je ono što radimo u projektaima ozbiljno; nekada se radi i o ljudskim životima.

Primer: Definisanje uloga i odgovornosti

Možeš prepustiti članovima projektanog tima da rade bez jasnih uloga i odgovornosti, i pre ili kasnije spontano će se iskristalisati neki oblik uloga I odgovornosti. Međutim, to će biti previše skupo i na kraju možda neće ni dobro funkcionisati. Proaktivni pristup bi bio definisati ih rano u projektu, i prilagođavati vremenom po potrebi. Ovo će uroditi lakšim radom za svakoga, tako da će se moći fokusirati na izvršenje nečega, umesto da odlučuju ko će šta da radi.

Broj i razvnovrsnost rola zavisi od tipa i veličine projektaa; najjednostavnija definicija je u Scrum-u, nešto prosečno složenosti kao u, ili nešto opsežno kao u DSDM® i PRINCE2®. Ipak, ne zaboravite da su opisi uloga u ovim metodama bitni samo za menadžment aktivnosti, a dodatno je potrebno definisati opise uloga za tehničke aspekte projektaa.

Primer: Raspoložive opcije izbora

Da li prerano zatvoriti projekat ili ga nastaviti?

Izbor retko ima samo dve opcije, čak i kada to samo pitanje implicira. Treba zauzeti proaktivan stav, i razmotriti sve opcije pre donošenja odluke. Možda se može redefinisati scope projektaa; možda se može pauzirati dok se neke stvari ne razjasne; možda se može promeniti projektani pristup (npr. Outsourcing) , itd.

Primer: Kritičko mišljenje

Svi imamo neke predrasude, i uvrežene stavove koje nam pomažu da preživimo (sa jedne strane), ali nas često i navode na donošenje loših odluka (sa druge strane). Kada dođe do donošenja važnih odluka o projektu, najbolje je napraviti pauzu na neko vreme, osvestiti sve predrasude koje mogu da utiču na naše odlučivanje, pre nego što prouzrokuju probleme.

Kao referencu, možete koristiti listu kognitivnih predrasuda datu na Wikipedii:

Postoje čak i framework-ovi za donošenje odluka koje možete koristiti kao alate za bolje odlučivanje. Na prvi pogled, oni mogu delovati zbunjuće, pa i iritantno, ali ćete se brzo navići na njihovo korišćenje i usvojiti njihove prednosti, bez puno svesnog napora.

Primer: Transparentnost

Ne volimo kašnjenje u projektu ili bilo kakvu drugu vrstu problema, ali to ne znači da to treba da krijemo. Treba biti transparentan i upoznati stakeholder-e sa tim, jer neki od njih će možda moći da pomognu, štaviše, saznaće o problemima i njihovim posledicama pre ili kasnije, a neki od njih će sa svoje strane možda zahtevati brzo dejstvo (npr. prihvatanje negativnih posledica)

Primer: Efektivna komunikacija

Može biti puno slučajeva u kojima šaljete izveštaje stakeholder-ima, a oni vam ne daju nikakvu povratnu informaciju. Možda ćete misliti da je sve u redu, jer nema negativne povratne informacije, iako možda nije tako. Treba biti proaktivan i proveriti da li se izveštaj zaista koristi i da li koristi svrsi, koristiti povratne informacije da bi se poboljšao metod komunikacije; u suprotnom, skrivena pitanja ili problemi mogu kasnije prouzrokovati znatno ozbiljnije probleme kasnije, kada bude mnogo teže da se poprave.

Primer: Uzimanje odgovornosti

Lako je okriviti druge za loše rezultate. Na primer, možda ćete želeti da vam organizacija da puno ovlašćenje da promenite sve u projektu i da uradite sve savršeno, ali to se ne desi, i kao rezultat, projekat propadne. OVO NIJE PROAKTIVAN PRISTUP.

Proaktivan pristup podrazumeva uzimanje odgovornosti da se uradi sve što je u okviru vaših projektanih ograničenja (scope, vreme, budžet, kvalitet itd..). Ne možete očekivati da vam organizacija da puno poverenje i dopusti sve u cilju postizanja dobrih rezultata, naročito ako ima prethodna iskustva sa propalim projektaima. Ono što treba da uradite je da napravite manja poboljšanja unutar ograničenja koja su vam data u projektu , iskoristite to da dobijete malo više poverenja, nešto više resursa i tolerancije na projektana ograničenja, a onda to iskoristite za značajnija poboljšanja projektaa, iznoseći ga sve dok ne dosegnete optimalni target.


Zapamti – lanac je jak onoliko koliko njegova najslabija karika

Postoje različiti domeni u projektaima svi oni zahtevaju pažnju; moramo imati holističku perspektivu projektaa. Obraćanje pažnje na naizgled važne domene (npr. vreme) nije dovoljno, jer svi domeni međusobno su zavisni (interaguju) i ne rade dobro dok ne dobiju adekvatnu pažnju.

Primer: Sve je do rokova !

Recimo da gradite nešto za Olimpijske igre. Rok je izuzetno blizu, što daje na značaju domenu upravljanja vremenom. Da li je baš tako?

Šta ako kvalitet nekih proizvoda projekta bude tako loš da je neophodno ponavljanje posle nekog vremena? To bi svakako uticalo na vreme, dakle važno je i vreme i kvalitet. Možda ste zamislili fantastičnu baštu u originalnoj definiciji projektaa, ali znajući da nemate dovoljno vremena, preskočićete kitnjaste detalje i samo prekriti travom, ukoliko ste na na vreme predvideli ovakvu situaciju i pripremili se za nju. Sve u svemu, i upravljanje scope-om je vrlo značajno. Da rezimiramo: u centru naše pažnje su sada scope, vreme i kvalitet.

Čuli ste za poznat primer kada je predsednik SAD Kenedi sreo domara u NASA-i, pitajući ga čime se bavi? Odgovor je bio: “Pomažem da se čovek popne na Mesec”. Zar prisustvo ovakvog tipa ljudi u projektu ne pomaže ispunjavanju rokova?

Ako bi nastavili tako dalje, primetili bi da svaki pojedinačni domen u projektu doprinosi upravljanju vremenom, i ne možete očekivati da ćete ispoštovati rokove sa prihvatljivim nivom izvesnosti, osim ako ne obratite pažnju na sve domene.

Primer: Pristrasna (nekritička) selekcija

Kada su ljudi suočeni sa širokom lepezom izbora (različiti metodi), ponekad biraju nekritički praveći miks svega što ima deluje interesantno iz različitih sistema. Ovo obično ne funkcioniše, jer elementi ne rade u izolaciji već moraju da su međusobno kompatibilni. Svi dodaci ili promene sistema treba raditi sa holističke tačke gledišta. Zbog toga ponekad vidimo kontradiktorne elemente u različitim metodama ; nešto radi dobro u jednom sistemu, a njegova suprotnost u drugom sistemu. Taj elemenat sam po sebi nije ni dobar ni loš – radi se o kontekstu korišćenja.

Najsigurniji pristup: izaberi metodologiju za projekat, skroji je po potrebama projektaa, a onda oprezno dodaj nove elemente, stalno imajući na umu konzistentnost celog sistema.

Primer: Anti-procesni pristup

Jedna od najboljih stvari koje su Agile metodi ostvarili jeste ukazivanje na ljudske aspekte. Agile Manifest poklanja veću pažnju individuama i interakcijama nego procesima i alatima, iako ovo možda nije fer poređenje. Skoro sve metode će reći da su ljudski aspekti važni, a stvarna razlika sa Agile metodama je da su ljudski aspekti ugrađeni deo procesa, pre nego puka sugestija. Dakle, ne radi se o takmičenju između ljudskih aspekata i procesa, radi se o načinu na koji su ljudski aspekti viđeni od strane sistema.

Nema sumnje da neki ljudi pokušavaju da zamene ljudske aspekte sofisticiranijim procesima, ali u pitanju je neadekvatna primena. Dešava se i suprotno: ljudi pokušavaju da zamene procese ljudskim aspektima, što takođe ne funkcioniše dobro.

Primer: Ovo su svi domeni koji ti trebaju

Razmišljajući o domenima, treba paziti da se ne ispusti nijedan od njih iz razmatranja. Ali šta su oni zapravo ? Proveravajući fundamentalne resurse, dobićemo različite odgovore; pa ipak nijedan ne sadrži punu istinu.

PRINCE2® “Teme” su domeni, ali to su samo domeni koju igraju ključnu ulogu u metodologiji. Ostali domeni se samo naslućuju.

PMBOK® Guide nije metodologija i može da formuliše to mnogo bolje pomoću 10 oblasti znanja. Ipak ovo su interpretacije domena zasnovane na pogledu PMBOK® Guide na projektae, pre nego neutralna perspektiva (koja u suštini i ne postoji). Na primer, ljudski aspekti ne dobijaju mnogo pažnje u PMBOK® Guide.

Dobar izvor informacija o domenima je ICB. Ipak, ne radi se toliko o domenima koliko o potrebnim kompetencama za projekat. Ne postoji relacija jedan-na-jedan sa domenima, ali prilično pomaže u njihovoj identifikaciji.

Nema liste domena u “NUPP”, primarno jer je u pitanju meta-sistem pre nego sistem, takođe i jer kategorizacija domena zavisi od tipa projekta i projektanog okruženja; npr. rutinski građevinski projekat možda zahteva drugu perspektivu od kreativnog istraživačkog projektaa.


Ne radi ništa bez jasne svrhe

Ne bi trebalo da radiš nešto osim ako nema jasnu svrhu. Zamisli dva paralelna sveta gde je sve isto osim toga što u jednom svetu razmišljaš o onome što radiš, a u drugom ne: koliko bi se razlikovala ta dva sveta? Da li je razlika vredna truda da se to (ne) uradi?

Ako ti nije jasna svrha i radiš nešto samo zato što i svi ostali to rade, ili svako kaže da je važno da se to radi, onda: * Možda u tvom slučaju to nema stvaran benefit, pa stoga ne dobijaš ništa radeći to; ili * Možda u tvom slučaju ima potencijalne benefite, ali pošto ti nije jasna svrha, način na koji to budeš radio možda ti neće pomoći da ostvariš te benefite.

Primer: Portfolija i programi

Ako si uključen u izbor i inicijaciju projekata, fokusiraj se na benefite i probleme koji treba da se reše pre nego na proizvod koj treba da realizuje ove stvari. Klasičan primer je proizvođač liftova koji je primao žalbe na brzinu svojih liftova, pa je pokrenuo više projekata da bi popravio brzinu liftova, ali bez potpunog uspeha. Ovo se nastavljalo sve dok nisu odlučili da se fokusiraju na problem (dosađivanje ili nelagodnost u liftu) umesto “prirodnog” rešenja (bržih liftova). Rezultat je bio taj da su dodali ogledala u liftove i rešili problem jednostavno i jevtino.

Zapamti da je za projektani menadžment uglavnom važno “raditi stvari na pravi način”, dok je za portfolio menadžment važno “raditi prave stvari”. Nije važno koliko dobro vodiš svojе projektae; neće dobro funkcionisati ukoliko radiš pogrešne projektae. Sve je u svrsi.

Primer: Projekat kao celina

Fleksibilnost proizvoda varira od projekta do projektaa. U nekim IT razvojnim projektaima, proizvod je potpuno fleksibilan i njegov finalni oblik zavisi od povratne informacije koje će uslediti nakon inkrementalnih faza proizvoda kroz projekat, što zahteva adaptivni (Agile) pristup. U praktičnom smislu ovo je kombinacija slojeva portfolija, programa i projekata i potreban je maksimum pažnje posvećen krajnjem cilju. Dobra ideja je dokumentovati svrhu i imati je uvek na dohvat ruke; to je jedna od svrha “vizije proizvoda”, kako se koristi u nekim Scrum projektaima. Akcenat na poslovnu vrednost u Agile projektaima je njegov način osiguranog usklađivanja sa svrhom.

U drugim vrstama projektaa, gde je proizvod relativno fiksan i postoje drugi mehanizami kontrole da proizvod zadovolji svrhu, moguće je da članovi projektanog tima pomere fokus sa svrhe na proizvod (otuda princip “fokus na proizvode” PRINCE2®), ali u najmanju ruku minimum pažnje posvećen svrsi je još uvek potreban da bi se obezbedilo da ono što se stvara služi svrsi, što se može ostvariti poređenjem predviđenih i očekivanih benefita (otuda princip “kontinualnog poslovnog pravdanja” i “business case” Tema u PRINCE2®).

Ako se projekat radi za eksternog klijenta, klijent želi svoju sopstvenu svrhu za projekat, a vaša kompanija će imati svoju svrhu. Potrebno je da razumete i koristite obe da bi stvarno uspeli.

Primer: Monitoring projektaa

Fokusiranje na krajnju svrhu je neophodno. Ali možda i previše apstraktno za većinu svakodnevnih primena. Za praktičnu primenu potrebno je uspostaviti hijerarhiju pokretača. Kao prvo, poslovno opravdanje i benefiti projekta definisani su shodno krajnjoj svrsi, a shodno njima eksplicitni i implicitni targeti za projektane varijable (tj. vreme, trošak, kvalitet) da bi se zadovoljilo poslovno opravdanje, što bi na kraju zadovoljilo krajnju svrhu. Ovo su svrhe nižeg nivoa koje su korisne za mnoge od naših dnevnih zadataka.

Kada se radi o monitoringu, monitoring nižeg nivoa u projektu pratiće varijable niženg nivoa, jer možda neće biti moguće pratiti krajnju svrhu. U ovom slučaju, ne treba zaboraviti na svrhu: šta je svrha monitoringa?

Normalan i prihvatljiv odgovor je videti da li dobro pratimo plan, ako ne, inicirati odgovarajuću reakciju koja će nas dovesti nazad na u okvire plana ili ponovo podesiti targete i videti da li konačna svrha još uvek može biti zadovoljena. Naša merenja stoga treba da nam pomognu oko ove svrhe nižeg nivoa, a odgovarajuća merenja su prognoze za projektane varijable na kraju projektaa; npr., kada ćemo moći da zavrišimo projekat? Koliko novca nam je potrebno da završimo projekat?

Sva druga merenja, kao što su planirane i aktuelne vrednost na dan, samo su međuvrednosti koje su nam potrebne da bi kalkulisali prognozu, a ne konačne vrednosti za svrhe menadžmenta.

Primer: Dokumenti

Bez obzria koji development pristup koristimo u projektu, planiranje je uvek neophodno. Važno pitanje je nivo detalja u svakom tipu plana. Ako nema dovoljno detalja u planu, plan neće moći dovoljno da doprinese, a izvršavanje projekta zasnivaće se na ad-hoc odlukama pre nego na integrisanim, holističkim. Sa druge strane, puno ljudi pokušava da bude oprezno, pa dodaje previše detalja u plan, što ga čini teškim za pripremu i održavanje, i previše rigidnim za neizvesnosti u projektu. Kao rezultat, plan postaje nerealan i beskoristan.

Najbolji način da se odluči o nivou detalja je imati svrhu na umu za svaki element u planu. Na primer, ako razmatraš dodavanje resursa u plan, to treba da ima svrhu: kako ćeš ga koristiti? Kako će to pomoći projektu? Koliko The best way to decide about the level of detail is to have a purpose in mind for every element in the plan. For example, if you’re considering the addition of resources to the plan, you should have a purpose for it: How are you going to use it? How will it help the project? Koliko napora će to proizvesti? I da li se isplati?

Ponekad se radi o tome da li želiš neki element u svojim planovima, a nekad o načinu na koji planiraš i pripremaš nešto. Bilo da je business case, projektana povelja, ili izveštaj: uvek se pitaj zašto pripremaš taj dokument i kako može da pomogne projektu.

Traženje raznih “template”-a po web-u je sušta suprotnost činjenja nečeg baziranog na svrsi.

Primer: Statusno izveštavanje

Česta je pojava predugih statusnih izveštaja u mnogim projektaima. Polazeći od ovog NUP-a, treba da se zapitamo koja je svrha izveštaja i kako je možemo postići bez obzira šta drugi rade po tom pitanju.

Ovo nas u mnogo slučajeva može voditi ka pripremi veoma jednostavnih izveštaja na jednoj stranici koje će stakeholderi zaista čitati i razumeti, za razliku od dugih izveštaja. Ovo je poklanjanje pažnje svrsi.

Ako pripremaš izveštaj od jedne strane, doduše neki ljudi mogu da i to zamere i misle da nemaš postavljen adekvatan monitoring sistem. U praksi, ovo kreira tebi sekundarnu svrhu (osim primarne, a to je pomoć stakeholderima da razumeju status projektaa), a da bi to zadovoljili, možete prosto kreirati drugi tip izveštaja koji će biti dugačak. Ipak, ne mešajte ova dva izveštaja, jer im je i svrha različitia.

Primer: Business case i projektana povelja

Pripreme dokumenata kao što je business case i projektana povelja obično je dosadna, jalova, birokratska neophodnost za većinu ljuid, dok svi ovi dokumenti imaju valjanu svrhu koja važi za većinu projekata. Ako pokušaš da pronađeš “template” i popuniš ga, vreme je protraćeno; umesto toga bolje je da proveriš pravu svrhu ovih dokumenata, vidiš da li i kako mogu biti od pomoći u projektu, a onda pripremiš dokument na način kako želiš, isključivo da zadovoljiš svrhu: to će onda biti pravi dokument.

Dok razmišljaš o načinu pripreme dokumenata da bi zadovoljili svoju svrhu, možda nećeš imati na umu svaki scenario i zato nešto propustiti. Da bi to izbegao, proveri sve resurse, kao npr. PRINCE2®, PMBOK® Guide,, I DSDM® sugestije, i onda evaluiraj ove sugestije zasnovano na svrsi.

Primer: Post-projekat

Sve dok projekat ima specifičnu svrhu (a svrhu možemo preispitivati tokom projektaa) , realizacija svrhe uglavnom se vrednuje na osnovu prognoza nastalih tokom projektaa. Ipak, ne smemo da zaboravimo na to ni kad se projekat završi. Važno je proveriti realizaciju ciljeva nakon kraja projektaa, jer:

  • Možemo videti kako se postižu krajnji ciljevi i učiti iz toga za buduće projektae, i,
  • Ponekad se ciljevi ostvare samo ako se obave neki dodatni zadaci nakon projektaa, a za razumevanje neophodnosti ovih ekstra zadataka potreban je monitoring.

Post-projektani monitoring je neophodan korak ako smo vođeni svrhom. Ovo je uglavnom odgovornost sistema za upravljanje progama i portfolia, a pošto većina kompanija nema takve nivoe menadžmenta, ovaj korak se obično zanemaruje. Zbog toga metodi kao and DSDM® dodaju ovaj korak u svoje metodologije projektanog menadžmenta.

Primer: Jednostavnost

Svet je kompleksan i haotičan, ali naši modeli su apstraktne aproksimacije koje odražavaju delove sveta, pa su stoga jednostavne. Sa druge strane, jednostavni sistemi obično funkcionišu bolje, jer možemo da se fokusiramo na glavnu ideju.

Mnogi od nas pokušavaju da dobiju bolje rezultate dodajući kompleksnost u sistem, nadajući se da će odslikati kompleksnost sveta, čak i ako u praksi ovo otežava rad sa sistemom i obično nas sprečava da zadovoljimo svrhu.

Primer: Prilagođavanje – “krojenje”

Softver za streaming muzike ima različite uslove od onog koji se koristi za opremu u bolnici ili u avionu gde od toga zavise ljudski životi, ili od softvera koji će se koristiti u satelitima gde treba da rade mnogo godina bez “pada sistema”. A svi pomenuti softverski projektai razlikuju se od izgradnje letnje vile, vatrogasne stanice, ili postrojenja za preradu.

Ako imate svrhu na umu, bolje ćete razumeti kako prilagodite – “skrojite” sisteme i artefakte za različite projektae.


Koristi ponovljive elemente

Ad hoc pristup projektu uzima previse energije i resursa, a uvek postoji i rizik izostavljanja nekog od neophodnih elemenata. Najbolji način da se pojednostavi ono što treba da bude se uradi, jeste koristiti ponovljive elemente, i po mogućstvu koristiti ih u ponovljivim ciklusima.

Primer: Ček-lista za kvalitet

Ček-lista je jednostavan primer potencijalno ponovljivog elementa koji koristi većina ljudi u svom privatnom i profesionalnom životu. Uzmimo kriterijume za kvalitet isporučenog projektanog proizvoda, na primer:

  • Prvo, može kreirati ček-listu SVIH kriterijuma, što je forma planiranja.
  • NUP6 predlaže da pokušate da generalizujete: ima li sličnih isporučenih proizvoda u projektu? U tom slučaju, pripremite generalnu ček-listu za kvalitet , za tu KATEGORIJU isporučenog proizvoda i koristite je za sve njih. Ako bude nekih varijacija, držite se generičke liste, pa dodajte nekoliko ekstra stavki za pojedine isporučene proizvode. Eto ponovljivih ček-listi.
  • Čim ste pripremili generičku ček-listu za različite kategorije isporučenih projektanih proizvoda, možete naći ponavljajuće elemente među njima, što sugeriše virtualnu “roditeljsku” kategoriju. U tom slučaju, umesto da ponavljate stavke za sve generičke ček-liste. Možete ih izvaditi i staviti u „roditeljsku“ ček-listu. Na kraju ćete verovatno imati jednu generičku ček-listu za ceo projekat. “Definicija urađenog” u Scrum-u (“definition of done”) je primer korišćenja ček-lista za kvalitet na nivou projekta (između ostalog). Radeći ovo, svaki projektani proizvod će pripadati negde u hijerarhiji kategorija i trebaće pri proveri kvaliteta da zadovolji stavke koje se pojavljuju u ček-listama svih kategorija u njihovom lancu.

Radeći ovo, Stavka u roditeljskoj ček-listi postaće ponovljiva za sve proizvode ispod nje, što štedi vreme i energiju u planiranju i izvršenju. Što je još važnije, kad ovo uradiš za jedan projekat, možeš je prilagoditi i koristiti za sve slične projektae ubuduće, što je ponovljivi oblik planiranja za više projekata.

Primer: Procesi i tokovi rada

Neki projektani proizvodi, ili ciljevi povezani sa njima, iziskuju određene korake koji mogu postati standardizovani i ponovljivi. Na primer, ako projektani proizvodi treba da se dizajniraju i odobravaju individualno , možete pripremiti jednostavan “workflow” koji jasno prikazuje sve korake, uključene osobe, i približna trajanja, time izbegavajući mnoge poteškoće. Ipak treba paziti ne učiniti procese previse komplikovanim ili previse intenzivnim pri dokumentovanju, jer će imati negativne posledice. Svi ljudi uključeni u projekat treba da shvate procese i tokove rada kao nešto što podupire i olakšava njihov rad, a ne kao birokratsko dokumentovanje koje blokira praktičan rad. Agilni projektai imaju ponovljive elemente u svom pristupu iterativnog razvoja, pri čemu se određen tip razvojnih aktivnosti ponavlja za svaku karakteristiku proizvoda (feature); npr. ista dnevna rutina u XP (eXtremno Programiranje):e.g. the common daily routine in XP (eXtreme Programming): upariti, uzeti stavku, dizajnirati je na beloj tabli, napraviti testne skripte i kod, integrisati kod, itd…

Osim ponovljivih procesa rada koji se koriste za tehničke aktivnosti, možemo imati ponovljive elemente i za aktivnosti projeknog menadžmenta. Procesi u PMBOK® Guide, PRINCE2®, i DSDM®, aktivnosti u, i događaji u Scrum su primeri ovog koncepta.

Primer: Ciklusi

Imati ponovljive elemente za upravljanje projektaom je od pomoći. Ovo može biti još lakše stavljajući ih u ponovljive cikluse. Ovi ciklusi značajno uprošćavaju svakodnevne aktivnosti ljudi uključenih u menadžment i vođstvo projektaa. Ciklusi procesnih grupa u PMBOK® Guide kada se koriste u projektu u više faza, faze (stages) u PRINCE2®, dnevni, nedeljni, i mesečni ciklusi u, iteracije i vremenske kutije u DSDM®, kao i Sprintovi u Scrum-u, sve su primeri ovog koncepta.

Kraći cikulsi su lakši za razumevanje i upotrebu nego duži; npr. Sprintovi u Scrum-u nasuprot fazama po PMBOK® Guide. Ipak, prekratki ciklusi možda neće biti dovoljni da iznesu određene tipove projekata, a rešenje može biti upotreba višestrukih ciklusa, kao što je u DSDM® upotreba kratkih ciklusa “vremenske kutije” u kombinaciji sa dužim iterativnim ciklusima, ili korišćenje dnevnih, nedeljnih i mesečnih ciklus u

Primer: Metode

Korišćenje metodologije ili framework-a za vođenje projekta je još jedan slučaj korišćenja ponovljivih elemenata. Ovo može biti postojeći sistem kao što je PRINCE2®,, DSDM®, ili Scrum, ili system koji ste prilagodili ili sami izmislili. Normalno, za početak je bolja ideja startovati sa nekim od postojećih metoda i prilagoditi je svojim potrebama, nego napraviti jednu “od nule”.

Svaki ponovljivi element je apstraktan i iziskuje kastomizaciju da bi ga prilagodili stvarnom svetu. Postoji spektar apstrakcije i potrebe za kastomizacijom, doduše: male, relativno fiksne ček-liste kvaliteta stoje na jednom kraju spektra sa malom količinom apstrakcije I potrebe za prekrajanjem, dok su metodologije na drugom kraju, sa visokom potrebom za prekrajanje. Treba uvek primetiti potrebu za prekrajanjem, u suprotnom ponovljivi element neće odggovarati vašim potrebama na potreban način.


“НУПП ” је скраћеница од „Nearly Universal Principles of Projects“ тј. означава збир “скоро универзалних принципа пројеката”: оних које би било добро следити у свим пројектима, без обзира на методологије и приступе које у њима употребљавамо, како би постигли максимални успех. Сваки од расположивих ресурса и метода за спровођење пројеката почива на НЕКИМ од ових “НУП”-ова (скоро универзалних принципа). Ипак, следеће ствари треба имати на уму:

  • “Почива на НЕКИМ” (подвучено у претходном пасусу): обично не на СВИМ, а практичарима пројектног менаџмента се управо препоручује да узму у обзир СВЕ “НУП”ове, а не само неке од њих.
  • У ресурсима и методима ови принципи (на којима се заснивају) нису довољно очигледни, па како је већина практичара пречесто фокусирана на практичне детаље, заборавља на принципе и ради ствари у нескладу са њима.

“НУП ”ови су компатибилни са свим важним методима, системима, ресурсима и фрамеwорк-овима као што су: PRINCE2®, PMBOK® Guidе,, PM², DSDM®, XP, и Scrum. Додуше , може се десити да нису компатибилни са одређеним интерпретацијама ових система, и управо у тим случајевима “НУП”ови треба да охрабре практичаре да преиспитају те интерпретације.

“НУПП” је збир следећих “НУП”ова:


Резултати и истина пре припадности

Сви ми имамо природну тенденцију да припадамо групама, тенденцију која често превазилази своју основну форму, креирајући снажне везе које могу изазвати и проблеме. Може се чак десити да изгубимо много више због тих веза него што добијемо у одређеним ситуацијама. Не тргујмо сопственим професионалним интегритетом, идентитетом и склоностима, за рачун припадности одређеној групи.

Пример : Agile против Waterfall-а

Група изузетних ентузијаста која је била довољно храбра да користи адаптивне приступе развоју унутар ИТ развоја, у време када се доминантно користио предиктивни приступ, окупила се и назвала свој приступ “Agile”. Ово је била сјајна иницијатива да се избегне ограничавање избора само на оно што се чинило неопходним. Још увек је пуно ентузијаста усмерених на резултат у Agile заједници, нажалост у њој има и неких који теже да Agile претворе у култ, посматрајући све ван ње у непријатеље. Ово ствара вишеструке проблеме, укључујући и следеће:

  • Спречава их да уче од било кога ван групе
  • Обесхрабрује оне ван групе да уче од њих
  • Ставља припадност групи испред стварне сврхе, што као резулат спречава припаднике групе да науче о стварном смислу „Агилности“

Овај проблем се може значајно умањити (ако не и отклонити), употребом речи “Agile” САМО као ознаке која се односи на развојни приступ, а не на заједницу са својим члановима; даље , уз помоћ ЉУДИ који сматрају себе креаторима, решаваоцима проблема, и лидерима којии виде “Agile” једноставно као ЈЕДАН ОД СВОЈИХ АЛАТА, А НЕ КАО СВОЈ ИДЕНТИТЕТ.

За праве професионалце не постоји рат “Agile” против “Waterfall”-а!

Пример : PRINCE2® против PMBOK® Guide

Многи професионалци у пројект менаџмент заједници се идентификују или са PRINCE2® методологијом или са PMBOK® framework-ом (често само због географске локације) и нису упознати са другом страном. Сви ми можемо нагињати одређеним ресурсима, али не доводећи свој професионални идентитет и интегритет у питање. Још важније, требало би да се фамилијаризујемо сва свима њима ширећи своје видике и могућности избора.

Прави професионалци су отворени за све идеје, тражећи их, учећи о њима, и користећи их када је потребно, без стварања некритичке припадности тј. везивања за исте.

Пример : Непрекидно учење

Везивања за одређене идеје или заједнице, задовољавају особу због пратећег осећаја припадности, али је не подстичу да учи, понекад чак и обесхрабрују због страха од губитка те исте припадности. Ако је особа слободна, ако је експерт са интегритетом испред припадности, стално ће попуњавати празнине у свом схватању учењем: непрекидним учењем.

ОНО У ШТА ДАНАС ВЕРУЈЕМО НИЈЕ ПОТПУНА ИСТИНА (ВЕЋ ВИШЕ НАШЕ ТРЕНУТНО РАЗУМЕВАЊЕ КОЈЕ ТРЕБА ПРОДУБИТИ), А СУТРА ВЕЋ МОЖЕ БИТИ ПОЛУИСТИНА. Ако су нечије идеје годинама фиксиране без икаквих промена, онда са њима нешто није реду. Ово је случај и за НУПП: ако се вратиш овде за неколико година и видиш потпуно исти садржај, треба да будеш сумњичав.

Пример : Отвореност

Када полемишеш или приговараш, буди сигуран да циљаш на идеју а не на особу. Ово ће помоћи да се смање тензије. Слично томе, када него полемише са тобом или ти приговара, не схватај то као рат против тебе, већ као дискусију о твојим идејама и остани отворен за примање. Не слушај да би одговорио, слушај да би разумео; ради са том особом на побољшању идеје.

Неки људи ће можда намерно “гађати” твоју личност уместо идеје, у ком случају треба да им помогнеш да се фокусирају на идеју уместо на тебе пре наставка дискусије. Покушај да ово одржаваш и у наставку дискусије.


Очувај и оптимизуј енергију и ресурсе

Ресурси су ограничени. Ресурси расположиви пројекту су ограничени, баш као и ментална енергија коју имаш за доношење добрих одлука. Треба да очуваш и оптимизујеш овај ресурс за себе и пројекат, као и да помогнеш другим члановима тима да ураде исто.

Пример : Правило 80/20 (Паретово правило)

Највећи део потенцијалних бенефита (рецимо 80%) од пројекног менаџмента добија се трошењем мањег дела (рецимо 20%) од укупно планираног напора потребног за достизање 100% бенефита. У већини случајева, циљајући 100% могућих бенефита је скупо и неоправдано. Треба следити ово правило у свему што радите и охрабрити друге да исто тако раде.

Пример : Замореност одлучивањем

Ми користимо један извор менталне енергије за све врсте одлучивања, као и да изразимо снагу воље. Ако ову енергију трошиш на мање важне или небитне одлуке, имаћеш мање енергије за важне одлуке, што може довести до лоших резултата. Ово је један од разлога зашто треба избећи “микро-менаџмент” (“управљај према изузетку” принцип PRINCE2®).

Конфликти који настају око идеја, могу да буду корисни, али они који настају око/због људи обично штете пројекту, а једна од последица је „цеђење“ менталне енергије чланова тима. Ако приметиш такав конфликт, дај све од себе да нађеш главни узрок и решиш га.

Пример : Побрини се за себе !

Одлуке које доносиш и снага воље коју изражаваш користе твој извор менталне енергије. Са друге стране, овај извор се допуњава када редовно спаваш и правилно се храниш. Дакле , потруди се око себе : спавај и одмарај довољно, храни се добро и правилно. Ако имаш штетне навике или проблеме са спавањем, не препуштај се сам себи ; постоје специјалисти који ти могу помоћи. Физичка активност такође помаже са овим извором енергије, иако истраживања по овом питању нису једногласна. Охрабри чланове тима да ураде исто што и ти. Прво , осигурај да раде одрживим темпом и без много прековременог рада. Затим , ако имаш ту врсту могућности, понуди им енергетску, здраву храну и пиће током радног времена.

Пример : Равнотежа између приватног и пословног

Многи од нас воле оно што раде, али то још увек није све што им треба у животу. На исти начин на који оптимизујеш свој посао треба да планираш и спроводиш идеје у свом приватном животу, тако да ти доносе радост и срећу. Када си срећнији, тада си и успешнији у послу. Охрабруј чланове тима да раде исто.

Пример : Мотивација

Мотивација је комплексан концепт. Постоје неки јако интересантни и корисни ресурси на ову тему, али још много више не-научно засновних. Ипак , треба да научиш о њима И непрекидно их користиш, јер тиме повећаваш менталну енергију тима И могућност постизања бољих резултата пројекта. Средства за мотивацију могу бити веома једноставна: дај људима на знање да препознајеш њихов добар рад, љубазним осмехом или једноставним “Хвала Ти!”. Опрез : многе честа средства за мотивацију, као што су мале новчане награде, могу имати и негативан ефекат.

Пример : Сарадња и тимски рад

Људи који сарађују могу некада имати моћ да побољшају резултате, али оно што је још важније, људи су друштвена бића и воле да су део групе. Ако им уклониш негативне аспекте тимског рада и направиш пријатно окружење, имаћеш срећније чланове тима у пројекту.

Опрез : људи су различити, тако да је некима потребније опуштено, фокусирано и самостално време, него другима – овде говоримо о балансирању потреба унутар тима.

Пример : Култура “један-тим”

Постоји тенденција да различити појединци или интересне групе (stakeholders) стварају или подржавају “кланове” и стварање тензија унутар групе или са другим групама; на пример, “људи фокусирани на пословни аспект” наспрам “људи који праве пројектни производ”. Оваква тензија може “украсти” пуно енергије обеју страна, и то је разлог више да радимо на томе да направимо културу “једног-тима” где сви раде ка истом циљу без обзира на улогу унутар пројекта.

Пример : Мудрост групе

Ако се скупи на једном месту већи број људи различитих профила да ради у модерираном окружењу (састанак, радионица, презентација, конференција…), овде постоји потенцијал за стварање јако добрих резултата, идеја, решења, чак и бољих него она која долазе од појединачних експерата.

Ако имаш ову могућност, користи је редовно да замолиш чланове тима да ти помогну у решавању сложених пројектних проблема. Осим добијања добрих резултата, друга предност је што тиме стављаш на знање члановима тима колико цениш њихово мишљење и да имају важну улогу у пројекту, што са друге стране подиже њихов ниво енергије и расположења. Активност #26 у је пример коришћења “мудрости групе” у пројектима.

Пример : Главни пројектни модератор

Ако си пројектни менаџер, већина ствари које радиш има природу модерације (или би требало да има). Са друге стране, можда приметиш да су чланови тима у прошлости имали лоша искуства са пројектним менаџерима, и да пројектују та искуства на садашњу ситуацију. То може утицати значајно на ваш однос:они троше значајан део енергије анализирајући твоје понашање, тражећи потенцијалне претње уместо да ти верују. У том случају, промени свој назив од “пројект менаџера” у “главног пројектног модератора”. На крају крајева, то је оно што стварно радиш у пројекту.


Увек буди проактиван

Постоји природна тенденција у нама да будемо реактивни. То нам помаже да очувамо енергију избегавајући бављење неважним стварима, или дати боље резултате у ситуацији када се суочимо са нечим где смо потпуно некомпетентни. Ове ситуације се разликују од пројеката, где проактивношћу постижемо много боље резултате.

Пример : Планирање

Ако возиш на неку нову локацију, а при томе касниш, започећеш вожњу ОДМАХ БЕЗ ПРИПРЕМЕ како би “уштедео време” и успут ћеш се хватати укоштац са евентуаним проблемима, онако како настају, импровизујући. Проактивни приступ би био: узети неко време пре почетка вожње, подесити навигациони систем да ти да најбржу руту засновану на густини саобраћаја, могућим инцидентима и блокадама дуж пута, ПА ТЕК ОНДА започети вожњу; то значи провести неко време пре ИЗВРШЕЊА путовања, да би избегао касније проблеме, и самим тим дошао до краја уз уштеду времена.

Насупрот томе шта неки људи мисле о Agile пројектима, ПЛАНИРАЊЕ ЈЕ УВЕК НЕОПХОДНО, ради се само типу и нивоу детаља у плановима. ПЛАНИРАЊЕ ПРЕ ИЗВРШЕЊА ЈЕ ПРОАКТИВНИ ПРИСТУП.

Сети се цитата: “Ако ми даш 6 сати да исечем цело дрво, првих сат времена провешћу у оштрењу секире”.

Ако је Предиктиван пројекат у питању, можеш да проведеш и 4 сата оштрећи секиру, ако си унапред сигуран да је циљ исећи цело дрво. У Агилном пројекту, ниси унапред сигуран да ли ћеш сећи дрво, скупљати разбијене гране, остатке од жетве, копати угаљ из рудника, или нешто друго. Па ипак, још увек мораш да обавиш генералну припрему за све то (да знаш где је најближа продавница алата), нешто специјалне припреме (оштрење) када се будеш фокусирао на одређено решење – то се зове планирање!

Пример : Планирање планирања

Планирање начина на који ћемо извршити пројекат је проактиван приступ. Ова проактивност се чак може проширит планирањем начина на који ћемо да планирамо извршење; то су нпр. Следећи концепти: “пројект менаџмент плана” код PMBOK® Gudie, менаџмент стратегија PRINCE2®, и приступа код DSDM®.

Пример : Непрекидно планирање

Реалност се ретко поклапа са оним што смо планирали, и то је ОК – али, морамо непрекидно да прилагођавамо наше планове како би били сигурни да остају реалистични и практични. То треба урадити одмах чим проценимо да је прилагођавање неопходно, а не тек онда када улетимо у проблеме. ТО ЈЕ ПРОАКТИВНИ ПРИСТУП.

Пример : Управљање ризицима

Цео концепт управљања ризицима се заснива на проактивности: када смо суочени са неизвесним догађајима, уместо да чекамо и гледамо шта ће се десити и тек онда регујемо на њих, ми већ унапред мислимо на ВЕРОВАТНОЋУ И УТИЦАЈЕ ових неизвесних догађаја, разматрамо одговоре на њих, и на крају и урадимо нешто унапред, како би их предупредили.

Обратите пажњу да је оно што радимо у пројектима озбиљно; некада се ради и о људским животима.

Пример : Дефинисање улога и одговорности

Можеш препустити члановима пројектног тима да раде без јасних улога и одговорности, и пре или касније спонтано ће се искристалисати неки облик улога И одговорности. Међутим , то ће бити превише скупо и на крају можда неће ни добро функционисати. Проактивни приступ би био дефинисати их рано у пројекту, и прилагођавати временом по потреби. Ово ће уродити лакшим радом за свакога, тако да ће се моћи фокусирати на извршење нечега, уместо да одлучују ко ће шта да ради. Број и развноврсност рола зависи од типа и величине пројекта; најједноставнија дефиниција је у Scrum-у, нешто просечно сложености као у, или нешто опсежно као у DSDM® и PRINCE2®. Ипак, не заборавите да су описи улога у овим методама битни само за менаџмент активности, а додатно је потребно дефинисати описе улога за техничке аспекте пројекта.

Пример : Расположиве опције избора

Да ли прерано затворити пројекат или га наставити?

Избор ретко има само две опције, чак и када то само питање имплицира. Треба заузети проактиван став, и размотрити све опције пре доношења одлуке. Можда се може редефинисати сцопе пројекта; можда се може паузирати док се неке ствари не разјасне; можда се може променити пројектни приступ (нпр. Outsourcing ) , итд.

Пример : Критичко мишљење

Сви имамо неке предрасуде, и уврежене ставове које нам помажу да преживимо (са једне стране), али нас често и наводе на доношење лоших одлука (са друге стране). Када дође до доношења важних одлука о пројекту, најбоље је направити паузу на неко време, освестити све предрасуде које могу да утичу на наше одлучивање, пре него што проузрокују проблеме.

Као референцу, можете користити листу когнитивних предрасуда дату на Википедији:

Постоје чак и framework-ови за доношење одлука које можете користити као алате за боље одлучивање. На први поглед, они могу деловати збуњуће, па и иритантно, али ћете се брзо навићи на њихово коришћење и усвојити њихове предности, без пуно свесног напора.

Пример : Транспарентност

Не волимо кашњење у пројекту или било какву другу врсту проблема, али то не значи да то треба да кријемо. Треба бити транспарентан и упознати стакехолдер-е са тим, јер неки од њих ће можда моћи да помогну, штавише, сазнаће о проблемима и њиховим последицама пре или касније, а неки од њих ће са своје стране можда захтевати брзо дејство (нпр. прихватање негативних последица)

Пример : Ефективна комуникација

Може бити пуно случајева у којима шаљете извештаје стакехолдер-има, а они вам не дају никакву повратну информацију. Можда ћете мислити да је све у реду, јер нема негативне повратне информације, иако можда није тако. Треба бити проактиван и проверити да ли се извештај заиста користи и да ли користи сврси, користити повратне информације да би се побољшао метод комуникације; у супротном, скривена питања или проблеми могу касније проузроковати знатно озбиљније проблеме касније, када буде много теже да се поправе.

Пример : Узимање одговорности

Лако је окривити друге за лоше резултате. На пример, можда ћете желети да вам организација да пуно овлашћење да промените све у пројекту и да урадите све савршено, али то се не деси, и као резултат, пројекат пропадне. ОВО НИЈЕ ПРОАКТИВАН ПРИСТУП.

Проактиван приступ подразумева узимање одговорности да се уради све што је у оквиру ваших пројектних ограничења (сцопе, време, буџет, квалитет итд..). Не можете очекивати да вам организација да пуно поверење и допусти све у циљу постизања добрих резултата, нарочито ако има претходна искуства са пропалим пројектима. Оно што треба да урадите је да направите мања побољшања унутар ограничења која су вам дата у пројекту , искористите то да добијете мало више поверења, нешто више ресурса и толеранције на пројектна ограничења, а онда то искористите за значајнија побољшања пројект , износећи га све док не досегнете оптимални таргет.


Запамти – ланац је јак онолико колико његова најслабија карика

Постоје различити домени у пројектима сви они захтевају пажњу; морамо имати холистичку перспективу пројекта. Обраћање пажње на наизглед важне домене (нпр. време) није довољно, јер сви домени међусобно су зависни (интерагују) и не раде добро док не добију адекватну пажњу.

Пример : Све је до рокова !

Рецимо да градите нешто за Олимпијске игре. Рок је изузетно близу, што даје на значају домену управљања временом. Да ли је баш тако?

Шта ако квалитет неких производа пројект буде тако лош да је неопходно понављање после неког времена? То би свакако утицало на време, дакле важно је и време и квалитет. Можда сте замислили фантастичну башту у оригиналној дефиницији пројекта, али знајући да немате довољно времена, прескочићете китњасте детаље и само прекрити травом, уколико сте на на време предвидели овакву ситуацију и припремили се за њу. Све у свему, и управљање сцопе-ом је врло значајно. Да резимирамо: у центру наше пажње су сада сцопе, време и квалитет.

Чули сте за познат пример када је председник САД Кенеди срео домара у НАСА-и, питајући га чиме се бави? Одговор је био: “Помажем да се човек попне на Месец”. Зар присуство оваквог типа људи у пројекту не помаже испуњавању рокова?

Ако би наставили тако даље, приметили би да сваки појединачни домен у пројекту доприноси управљању временом, и не можете очекивати да ћете испоштовати рокове са прихватљивим нивом извесности, осим ако не обратите пажњу на све домене.

Пример : Пристрасна (некритичка) селекција

Када су људи суочени са широком лепезом избора (различити методи), понекад бирају некритички правећи микс свега што има делује интересантно из различитих система. Ово обично не функционише, јер елементи не раде у изолацији већ морају да су међусобно компатибилни. Сви додаци или промене система треба радити са холистичке тачке гледишта. Због тога понекад видимо контрадикторне елементе у различитим методама ; нешто ради добро у једном систему, а његова супротност у другом систему. Тај елеменат сам по себи није ни добар ни лош – ради се о контексту коришћења.

Најсигурнији приступ: изабери методологију за пројекат, скроји је по потребама пројекта, а онда опрезно додај нове елементе, стално имајући на уму конзистентност целог система.

Пример : Анти-процесни приступ

Једна од најбољих ствари које су Agile методи остварили јесте указивање на људске аспекте. Agile манифест поклања већу пажњу индивидуама и интеракцијама него процесима и алатима, иако ово можда није фер поређење. Скоро све методе ће рећи да су људски аспекти важни, а стварна разлика са Агиле методама је да су људски аспекти уграђени део процеса, пре него пука сугестија. Дакле , не ради се о такмичењу између људских аспеката и процеса, ради се о начину на који су људски аспекти виђени од стране система.

Нема сумње да неки људи покушавају да замене људске аспекте софистициранијим процесима, али у питању је неадекватна примена. Дешава се и супротно: људи покушавају да замене процесе људским аспектима, што такође не функционише добро.

Пример : Ово су сви домени који ти требају

Размишљајући о доменима, треба пазити да се не испусти ниједан од њих из разматрања. Али шта су они заправо ? Проверавајући фундаменталне ресурсе, добићемо различите одговоре; па ипак ниједан не садржи пуну истину.

PRINCE2® “Теме” су домени, али то су само домени коју играју кључну улогу у методологији. Остали домени се само наслућују.

PMBOK® Gudie није методологија и може да формулише то много боље помоћу 10 области знања. Ипак ово су интерпретације домена засноване на погледу PMBOK® Gudie на пројекте, пре него неутрална перспектива (која у суштини и не постоји). На пример, људски аспекти не добијају много пажње у PMBOK® Guide.

Добар извор информација о доменима је ICB. Ипак , не ради се толико о доменима колико о потребним компетенцама за пројекат. Не постоји релација један-на-један са доменима, али прилично помаже у њиховој идентификацији.

Нема листе домена у “НУПП”, примарно јер је у питању мета-систем пре него систем, такође и јер категоризација домена зависи од типа пројект и пројектног окружења; нпр. рутински грађевински пројекат можда захтева другу перспективу од креативног истраживачког пројекта.


Не ради ништа без јасне сврхе

Не би требало да радиш нешто осим ако нема јасну сврху. Замисли два паралелна света где је све исто осим тога што у једном свету размишљаш о ономе што радиш, а у другом не: колико би се разликовала та два света? Да ли је разлика вредна труда да се то (не) уради?

Ако ти није јасна сврха и радиш нешто само зато што и сви остали то раде, или свако каже да је важно да се то ради, онда: * Можда у твом случају то нема стваран бенефит, па стога не добијаш ништа радећи то; или * Можда у твом случају има потенцијалне бенефите, али пошто ти није јасна сврха, начин на који то будеш радио можда ти неће помоћи да оствариш те бенефите.

Пример : Портфолија и програми

Ако си укључен у избор и иницијацију пројеката, фокусирај се на бенефите и проблеме који треба да се реше пре него на производ кој треба да реализује ове ствари. Класичан пример је произвођач лифтова који је примао жалбе на брзину својих лифтова, па је покренуо више пројеката да би поправио брзину лифтова, али без потпуног успеха. Ово се настављало све док нису одлучили да се фокусирају на проблем (досађивање или нелагодност у лифту) уместо “природног” решења (бржих лифтова). Резултат је био тај да су додали огледала у лифтове и решили проблем једноставно и јевтино.

Запамти да је за пројектни менаџмент углавном важно “радити ствари на прави начин”, док је за портфолио менаџмент важно “радити праве ствари”. Није важно колико добро водиш своје пројекте; неће добро функционисати уколико радиш погрешне пројекте. Све је у сврси.

Пример : Пројекат као целина

Флексибилност производа варира од пројект до пројекта. У неким ИТ развојним пројектима, производ је потпуно флексибилан и његов финални облик зависи од повратне информације које ће уследити након инкременталних фаза производа кроз пројекат, што захтева адаптивни (Agile) приступ. У практичном смислу ово је комбинација слојева портфолија, програма и пројеката и потребан је максимум пажње посвећен крајњем циљу. Добра идеја је документовати сврху и имати је увек на дохват руке; то је једна од сврха “визије производа”, како се користи у неким Scrum пројектима. Акценат на пословну вредност у Agile пројектима је његов начин осигураног усклађивања са сврхом.

У другим врстама пројекта, где је производ релативно фиксан и постоје други механизами контроле да производ задовољи сврху, могуће је да чланови пројектног тима помере фокус са сврхе на производ (отуда принцип “фокус на производе” PRINCE2®), али у најмању руку минимум пажње посвећен сврси је још увек потребан да би се обезбедило да оно што се ствара служи сврси, што се може остварити поређењем предвиђених и очекиваних бенефита (отуда принцип “континуалног пословног правдања” и “business case” Тема у PRINCE2®).

Ако се пројекат ради за екстерног клијента, клијент жели своју сопствену сврху за пројекат, а ваша компанија ће имати своју сврху. Потребно је да разумете и користите обе да би стварно успели.

Пример : Мониторинг пројекта

Фокусирање на крајњу сврху је неопходно. Али можда и превише апстрактно за већину свакодневних примена. За практичну примену потребно је успоставити хијерархију покретача. Као прво, пословно оправдање и бенефити пројект дефинисани су сходно крајњој сврси, а сходно њима експлицитни и имплицитни таргети за пројектне варијабле (тј. време, трошак, квалитет) да би се задовољило пословно оправдање, што би на крају задовољило крајњу сврху. Ово су сврхе нижег нивоа које су корисне за многе од наших дневних задатака.

Када се ради о мониторингу, мониторинг нижег нивоа у пројекту пратиће варијабле ниженг нивоа, јер можда неће бити могуће пратити крајњу сврху. У овом случају, не треба заборавити на сврху: шта је сврха мониторинга?

Нормалан и прихватљив одговор је видети да ли добро пратимо план, ако не, иницирати одговарајућу реакцију која ће нас довести назад на у оквире плана или поново подесити таргете и видети да ли коначна сврха још увек може бити задовољена. Наша мерења стога треба да нам помогну око ове сврхе нижег нивоа, а одговарајућа мерења су прогнозе за пројектне варијабле на крају пројекта; нпр ., када ћемо моћи да завришимо пројекат? Колико новца нам је потребно да завршимо пројекат?

Сва друга мерења, као што су планиране и актуелне вредност на дан, само су међувредности које су нам потребне да би калкулисали прогнозу, а не коначне вредности за сврхе менаџмента.

Пример : Документи

Без обзриа који девелопмент приступ користимо у пројекту, планирање је увек неопходно. Важно питање је ниво детаља у сваком типу плана. Ако нема довољно детаља у плану, план неће моћи довољно да допринесе, а извршавање пројект засниваће се на ад-хоц одлукама пре него на интегрисаним, холистичким. Са друге стране, пуно људи покушава да буде опрезно, па додаје превише детаља у план, што га чини тешким за припрему и одржавање, и превише ригидним за неизвесности у пројекту. Као резултат, план постаје нереалан и бескористан.

Најбољи начин да се одлучи о нивоу детаља је имати сврху на уму за сваки елемент у плану. На пример, ако разматраш додавање ресурса у план, то треба да има сврху: како ћеш га користити? Како ће то помоћи пројекту? Колико напора ће то произвести? И да ли се исплати?

Понекад се ради о томе да ли желиш неки елемент у својим плановима, а некад о начину на који планираш и припремаш нешто. Било да је business case, пројектна повеља, или извештај: увек се питај зашто припремаш тај документ и како може да помогне пројекту.

Тражење разних “template”-а по wеб-у је сушта супротност чињења нечег базираног на сврси.

Пример : Статусно извештавање

Честа је појава предугих статусних извештаја у многим пројектима. Полазећи од овог НУП-а, треба да се запитамо која је сврха извештаја и како је можемо постићи без обзира шта други раде по том питању.

Ово нас у много случајева може водити ка припреми веома једноставних извештаја на једној страници које ће stakeholder-и заиста читати и разумети, за разлику од дугих извештаја. Ово је поклањање пажње сврси.

Ако припремаш извештај од једне стране, додуше неки људи могу да и то замере и мисле да немаш постављен адекватан мониторинг систем. У пракси, ово креира теби секундарну сврху (осим примарне, а то је помоћ стакехолдерима да разумеју статус пројекта), а да би то задовољили, можете просто креирати други тип извештаја који ће бити дугачак. Ипак , не мешајте ова два извештаја, јер им је и сврха различитиа.

Пример : Business case и пројектна повеља

Припреме докумената као што је business case и пројектна повеља обично је досадна, јалова, бирократска неопходност за већину људи, док сви ови документи имају ваљану сврху која важи за већину пројеката. Ако покушаш да пронађеш “темплате” и попуниш га, време је протраћено; уместо тога боље је да провериш праву сврху ових докумената, видиш да ли и како могу бити од помоћи у пројекту, а онда припремиш документ на начин како желиш, искључиво да задовољиш сврху: то ће онда бити прави документ.

Док размишљаш о начину припреме докумената да би задовољили своју сврху, можда нећеш имати на уму сваки сценарио и зато нешто пропустити. Да би то избегао, провери све ресурсе, као нпр. PRINCE2®, PMBOK® Gudie,, И DSDM® сугестије, и онда евалуирај ове сугестије засновано на сврси.

Пример : Пост-пројекат

Све док пројекат има специфичну сврху (а сврху можемо преиспитивати током пројекта) , реализација сврхе углавном се вреднује на основу прогноза насталих током пројекта. Ипак , не смемо да заборавимо на то ни кад се пројекат заврши. Важно је проверити реализацију циљева након краја пројекта, јер:

  • Можемо видети како се постижу крајњи циљеви и учити из тога за будуће пројекте, и,
  • Понекад се циљеви остваре само ако се обаве неки додатни задаци након пројекта, а за разумевање неопходности ових екстра задатака потребан је мониторинг.

Пост -пројектни мониторинг је неопходан корак ако смо вођени сврхом. Ово је углавном одговорност система за управљање прогама и портфолиа, а пошто већина компанија нема такве нивое менаџмента, овај корак се обично занемарује. Због тога методи као и DSDM® додају овај корак у своје методологије пројектног менаџмента.

Пример : Једноставност

Свет је комплексан и хаотичан, али наши модели су апстрактне апроксимације које одражавају делове света, па су стога једноставне. Са друге стране, једноставни системи обично функционишу боље, јер можемо да се фокусирамо на главну идеју.

Многи од нас покушавају да добију боље резултате додајући комплексност у систем, надајући се да ће одсликати комплексност света, чак и ако у пракси ово отежава рад са системом и обично нас спречава да задовољимо сврху.

Пример : Прилагођавање – “кројење”

Софтвер за streaming музике има различите услове од оног који се користи за опрему у болници или у авиону где од тога зависе људски животи, или од софтвера који ће се користити у сателитима где треба да раде много година без “пада система”. А сви поменути софтверски пројекти разликују се од изградње летње виле, ватрогасне станице, или постројења за прераду.

Ако имате сврху на уму, боље ћете разумети како прилагодите – “скројите” системе и артефакте за различите пројекте.


Користи поновљиве елементе

Ad-hoc приступ пројекту узима превисе енергије и ресурса, а увек постоји и ризик изостављања неког од неопходних елемената. Најбољи начин да се поједностави оно што треба да буде се уради, јесте користити поновљиве елементе, и по могућству користити их у поновљивим циклусима.

Пример : Чек-листа за квалитет

Чек -листа је једноставан пример потенцијално поновљивог елемента који користи већина људи у свом приватном и професионалном животу. Узмимо критеријуме за квалитет испорученог пројектног производа, на пример:

  • Прво , може креирати чек-листу СВИХ критеријума, што је форма планирања.
  • НУП6 предлаже да покушате да генерализујете: има ли сличних испоручених производа у пројекту? У том случају, припремите генералну чек-листу за квалитет , за ту КАТЕГОРИЈУ испорученог производа и користите је за све њих. Ако буде неких варијација, држите се генеричке листе, па додајте неколико екстра ставки за поједине испоручене производе. Ето поновљивих чек-листи.
  • Чим сте припремили генеричку чек-листу за различите категорије испоручених пројектних производа, можете наћи понављајуће елементе међу њима, што сугерише виртуалну “родитељску” категорију. У том случају, уместо да понављате ставке за све генеричке чек-листе. Можете их извадити и ставити у „родитељску“ чек-листу. На крају ћете вероватно имати једну генеричку чек-листу за цео пројекат. “Дефиниција урађеног” у Scrum-у (“definition of done”) је пример коришћења чек-листа за квалитет на нивоу пројект (између осталог). Радећи ово, сваки пројектни производ ће припадати негде у хијерархији категорија и требаће при провери квалитета да задовољи ставке које се појављују у чек-листама свих категорија у њиховом ланцу.

Радећи ово, ставка у родитељској чек-листи постаће поновљива за све производе испод ње, што штеди време и енергију у планирању и извршењу. Што је још важније, кад ово урадиш за један пројекат, можеш је прилагодити и користити за све сличне пројекте убудуће, што је поновљиви облик планирања за више пројеката.

Пример : Процеси и токови рада

Неки пројектни производи, или циљеви повезани са њима, изискују одређене кораке који могу постати стандардизовани и поновљиви. На пример, ако пројектни производи треба да се дизајнирају и одобравају индивидуално , можете припремити једноставан “workflow” који јасно приказује све кораке, укључене особе, и приближна трајања, тиме избегавајући многе потешкоће. Ипак треба пазити не учинити процесе превисе компликованим или превисе интензивним при документовању, јер ће имати негативне последице. Сви људи укључени у пројекат треба да схвате процесе и токове рада као нешто што подупире и олакшава њихов рад, а не као бирократско документовање које блокира практичан рад. Агилни пројекти имају поновљиве елементе у свом приступу итеративног развоја, при чему се одређен тип развојних активности понавља за сваку карактеристику производа (феатуре); нпр. иста дневна рутина у XP (еXтремно Програмирање):упарити, узети ставку, дизајнирати је на белој табли, направити тестне скрипте и код, интегрисати код, итд…

Осим поновљивих процеса рада који се користе за техничке активности, можемо имати поновљиве елементе и за активности пројекног менаџмента. Процеси у PMBOK® Guide, PRINCE2®, и DSDM®, активности у, и догађаји у Scrum су примери овог концепта.

Пример : Циклуси

Имати поновљиве елементе за управљање пројектом је од помоћи. Ово може бити још лакше стављајући их у поновљиве циклусе. Ови циклуси значајно упрошћавају свакодневне активности људи укључених у менаџмент и вођство пројекта. Циклуси процесних група у PMBOK® Guide када се користе у пројекту у више фаза, фазе (стагес) у PRINCE2®, дневни, недељни, и месечни циклуси у, итерације и временске кутије у DSDM®, као и Спринтови у Scrum-у, све су примери овог концепта.

Краћи цикулси су лакши за разумевање и употребу него дужи; нпр. Спринтови у Srum-у насупрот фазама по PMBOK® Guide. Ипак , прекратки циклуси можда неће бити довољни да изнесу одређене типове пројеката, а решење може бити употреба вишеструких циклуса, као што је у DSDM® употреба кратких циклуса “временске кутије” у комбинацији са дужим итеративним циклусима, или коришћење дневних, недељних и месечних циклус у

Пример : Методе

Коришћење методологије или фрамеwорк-а за вођење пројект је још један случај коришћења поновљивих елемената. Ово може бити постојећи систем као што је PRINCE2®,, DSDM®, или Scrum, или сyстем који сте прилагодили или сами измислили. Нормално , за почетак је боља идеја стартовати са неким од постојећих метода и прилагодити је својим потребама, него направити једну “од нуле”.

Сваки поновљиви елемент је апстрактан и изискује кастомизацију да би га прилагодили стварном свету. Постоји спектар апстракције и потребе за кастомизацијом, додуше: мале, релативно фиксне чек-листе квалитета стоје на једном крају спектра са малом количином апстракције И потребе за прекрајањем, док су методологије на другом крају, са високом потребом за прекрајање. Треба увек приметити потребу за прекрајањем, у супротном поновљиви елемент неће одгговарати вашим потребама на потребан начин.


NUPP是英文单词Nearly Universal Principles of Projects的缩写词,顾名思义,NUPP是项目通用原则的集合:无论我们使用什么样的方法论和方法,最好在所有项目中都能够遵循这些原则,以便能够最大化的提高项目的成功率。 项目中的每个人和项目中使用的每个方法,通常只会关注这些项目通用原则(NUPs)的一部分内容,但是:

  • 对于从业者来说,考虑全部的这些项目通用原则,而不仅仅是其中的一部分会更有帮助。
  • 因为,如果对这些项目基本原则的理解还不够清晰的话,很多从业者往往会深入到实际的细节当中,而忘记了这些原则,并因此做了与这些原则相违背的事情。

项目通用原则(NUPP)兼容所有主要方法、体系、资源和框架,如PRINCE2®,PMBOK® Guide,,PM², DSDM®,XP和Scrum,虽然它可能与这些体系中的某些解释不一致,实际上,项目通用原则(NUPP)鼓励从业者重新考虑这些解释。 这里介绍的项目通用原则(NUPs)包括:



我们都有一种自然的倾向,即认为我们隶属于某些群体,这种倾向往往超出了其本身,使我们产生强烈的隶属关系,并因此导致一些问题。 因为这些隶属关系,我们失去的东西比获得东西还要多。 如果我们不将我们的身份和偏好限制在某些群体中的话,我们就可以成为更专业和更成功的专家。



  • 不允许他们向群体外的任何人学习
  • 不鼓励群体外人学习他们
  • 属于这个群体要比真正的目的更重要,这阻止了许多成员学习敏捷的真正含义




社区中有许多专业人士将要么将自己与PRINCE2®关联,要么与PMBOK®指南关联(通常是因为他们的所处的位置),这实际上并不是他们对某一个更加熟悉。 我们都可以对某些资源有所偏爱,但他们不是我们的标志,更重要的是,我们必须熟悉所有这些资源,以拓宽我们的视野和选择。



隶属关系可以让一个人通过产生归属感而获得满足,但是这种关系并不会推动他们学习,有时甚至因为担心失去他们,而不鼓励他们学习。 当你是一个自由的人、一个没有隶属关系的专家时,你需要通过学习,持续的来学习来填补空白。

我们今天所认为的并不是事实,而是到目前为止我们最好的理解,它需要我们持续改进。 如果一个人的想法与他几年前的想法完全相同,那肯定是出了问题。 甚至对于基项目通用原则(NUPP)来说就是这样,如果你在几年后回过头来,看到完全相同的东西,你肯定会提出质疑。


当拒绝某个人的时候,请确保你的目的是拒绝那个人的想法,而不是那个人。 这有助于防止很多紧张的情形发生。 同样地,当某人拒绝你或关注你的时候,尽量不要把它当作是针对你的战争,而是在讨论你的想法,并对其保持开放态度。 不要听他是如何回应的,而是要听他是如何理解的; 并与这个人一起提升这个想法。




资源是有限的, 对于项目来说可用的资源也是有限的,你做出正确决策的所花的精力也是如此。 你应该将精力和资源用在最重要的事情上,并帮助其他团队成员也这样做。


在项目管理中,通过花费一小部分的努力,可以获得大部分可能的收益。 在大多数情况下,以100%可能收益作为目标来实现,需要付出高昂的代价,并且这样做也是不合理的。 你在做每件事情的时候都需要考虑这个法则,并且鼓励其他人也这样做。


我们使用有限的精力来完成所有类型的决策,并且还想要把这些事情做好。 如果你耗尽了大量的精力在不必要或不重要的决策上,那么就没有精力来做重要的决策了,这可能会导致糟糕的结果。 这是你应该避免微观管理的原因之一(PRINCE2®提出“例外管理”原则也是这样的道理)。大家对想法的冲突可能是有益的,但与人有关的冲突通常会对项目造成伤害,其中后果之一就是它会耗尽团队成员的精力。 如果你发现这种冲突,应该尽力找到根本原因,并解决它。


你做出的决策和你表达的意愿都会消耗你的精力。 另一方面,通过休息和吃饭又会充实你的精力。 所以,你应该关爱自己:确保你有足够的睡眠和休息,并且营养充足。 如果你的睡眠习惯不好或有问题,你不必独自处理它,有很多专家可以帮助你解决这些问题。 运动也有助于充实你的精力,尽管这方面的研究尚无定论。尽量鼓励团队成员像你一样做这些事情。 首先,确保他们稳步的工作,不要有太多的加班。 然后,如果你有选择的话,请尝试在工作期间提供补充活力的健康食品,点心和饮料。


我们中的许多人都喜欢自己的工作,但是,工作不是我们生活中的一切。 与改善工作的方式一样,你应该在个人生活中规划和实施一些创意,使你更快乐。 你越快乐,你的工作就越成功。 如果可以,请尝试鼓励你的团队成员也这样做。


激励是一个复杂的概念。 关于这个主题有一些有趣和有用的资源,也有一些不够科学。 但是,你应该了解它并持续使用它,因为它可以增加团队的活力以及提高项目取得更好结果的可能性。激励可以很简单,比如通过善意的微笑或简单的“谢谢”让人们知道你认可他们工作。 但是,你也需要小心,因为许多常见的激励形式,如货币奖励,可能会产生负面影响。


善于协作的人可以创造更好的结果,但更重要的是,人类喜欢社交,并乐于成为团队的一员。 如果你可以消除团队合作的负面影响并创造一个愉快的环境,那么项目中的团队成员会更加快乐。但是,你应该小心,因为每个人是不同的,有些人需要比其他人更放松、专注和孤独的时间; 这通常是一种平衡行为。


不同的利益相关方都有创建或考虑小群体的倾向,并与其他群体产生紧张关系; 例如,关注项目业务方面的人员与正在构建产品的人员之间。 这种紧张感消耗了双方的大量精力,这也是我们应该努力建立单一团队文化的原因之一,每个人都朝着一个目标共同努力。


当大量各具特色的人聚集在一起,并在一个方便协作的环境中工作时,有可能获得非常好的结果、想法和解决方案,这种结果甚至可能比来自同一类专家提供的结果更好。如果你有这样的选择,你可以定期使用它来请求团队成员帮助你解决项目中的难题。 除了获得良好结果的可能性之外,它还会使团队成员了解到他们的意见是得到认可的,他们在项目中发挥着重要的作用,从而使他们愿意提供更大的贡献。 P3.express中的活动#26是在项目中使用群体智慧的一个示例。


如果你是项目经理,那么你所做的大多数事情都具有推进的特性(或者至少应该具有推进的特性)。 另一方面,你可能会发现,过去曾与项目经理有过不愉快经历的团队成员,那么这些经历会影响他们与你的关系:他们的一部分精力用于分析你对他的潜在威胁的行为,而不是与你建立信任关系,在这种情况下,你可以将你的头衔从项目经理更改为首席项目推进者。 毕竟,这就是你在项目中真正在做的事情。



我们有一种自然的倾向,那就是被动反应。 这可以帮助我们保持精力来处理不重要的事情,或者当我们处理我们完全无能为力的事情时,它可以给我们更好的结果。 这些情况与我们的项目不同,在项目中我们只能积极主动才能够获得更好的结果。







对我们执行项目的方式进行规划是一种积极主动的方法。 这种主动性可以通过对我们打算规划执行的方式进行扩展; 这是PMBOK®指南的管理计划、PRINCE2®的管理策略以及DSDM®中的方法的概念。有也有人将其称谓治理。


现实很少符合我们的计划,这没关系 - 但是,我们必须不断调整我们的计划,以确保它们仍然是切实和可行的。 我们应该在需要调整时尽快调整,而不是在我们遇到问题时才考虑。 这是一种主动的方法。


风险管理的整个概念是基于主动性的:当面对不确定的事件时,我们不是等待着,看到底发生的什么样的事情,然后才作出反应,而是要考虑其概率和影响,考虑应对措施,并在事件发生之前做些什么。 请注意,我们在项目中所做的事情是严肃的; 它有时是事关人们的生命 。


你可以让项目团队成员在没有明确角色和职责的情况下工作,迟早会出现某种形式的角色和职责,但是代价非常高而且效果可能不好。积极主动的方法是尽早定义角色和职责,并根据需要进行调整。 这使得每个人的工作变得更轻松,他们可以专注于提供某些东西,而不是决定谁做什么。

角色的数量和种类取决于项目的类型和规模; 它可以是一个简单的定义,例如Scrum中的定义,比如P3.express中的定义,或者像DSDM®和PRINCE2®中那样很全面的定义。 但是,不要忘记这些方法中的角色描述仅涉及管理活动,你还需要为技术方面的活动添加角色描述。


你是应该提前收尾项目还是继续开展项目?,很少只有两种选择,即使问题给出了暗示。 在做出决定之前,你需要采取积极主动的方法并考虑所有选项。 也许你可以重新审视这个项目; 也许你可以暂停,直到其他一些事情变得清晰; 或者你可以改变项目方法(例如,外包)等。


我们都有许多偏见,这一方面有助于我们的生存,另一方面也会蒙蔽我们,导致做出错误的决定。 在做出关于项目的重要决策时,最好暂停一段时间,并考虑所有可能在问题出现之前影响我们的决策的偏见。 作为参考,你可以使用维基百科中给出的认知偏差列表:

甚至可以使用决策框架来做出更好的决策。 起初,使用它们可能会令人分心甚至烦恼,但很快你就会习惯它们,并在没有太多意识努力的情况下从中获益。


我们不喜欢项目延迟到或遇到任何其他问题,但这并不意味着我们应该隐藏它。 你应该让他透明,让利益相关方知道,因为他们中的一些人可能能够帮助你,而且他们迟早会知道这个问题及其后果,其中一些可能需要他们的早期行动(例如 ,接受负面后果)。


在很多情况下,你可能会向利益相关方发送报告,但他们并未向您提供任何反馈。 你可能认为一切顺利,因为没有负面反馈,尽管可能不是这样。 你必须积极主动并检查他们是否真的使用了报告以及是否达到了目的,并使用这个输入来调整你的沟通方式; 否则,这个隐藏的问题可能会在以后成为严重问题,到那时就太难解决了。


很容易将糟糕的结果归咎于其他人。 例如,你可能希望你的组织赋予你所有权限,可以更改项目中的所有内容,然后完美地执行,但是,组织不会这么做,因此项目失败了。 这不是一种主动的方法。 积极主动的方法是承担责任,并在约束范围内尽一切努力做每件事情。 你不能指望组织完全信任你,并为你提供希望获得良好的结果一切,特别是当他们看到这么多项目都失败了的时候。 你要做的就是在设定的约束条件下做出一个小的提升,用它来获取一点信任,然后,使用更多一点的资源,并在更多的限制约束条件下,获取更大一点的提升,如此执行,直到达到最佳目标。



项目的各个方面都需要关注; 我们必须对项目有一个整体的视角关注。 只关注一个看似重要的方面(例如,时间)是不够的,因为所有方面都是相互关联的,只有它们都得到足够的关注才会有效。






当人们面对各种各样的方法时,有时候他们会选择性失明,并创造出一个来自不同体系的、看似有趣的一个混合体, 这通常并不当用,因为元素无法独立生效,必须要相互兼容。 在一个体系中添加或更改任何的内容都应该从整体的角度来开展。

这就是为什么我们有时候会在不同方法中看到一些矛盾的元素; 这些元素在一个体系中运行良好,而在另一个体系中就不行了。 该元素本身并没有什么对错。



敏捷方法所做的最好的事情之一就是引起对人的方面的关注。 与流程和工具相比,敏捷宣言为个人和人与人的互动提供了更多价值,尽管这可能不是一个公平的比较。 几乎所有的方法都说人的方面很重要,而敏捷方法与其他方法的真正区别在于人的方面是其流程的一个植入部分,而不是一个简单的建议。 因此,它不是关于人的方面和流程之间的竞争,而是关于人的方面在系统中如何被看待的方式。

毫无疑问,有些人试图通过更复杂的流程来取代人的方面,但这只是一种误用。 甚至相反的情况也存在:人们试图用人的方面取代流程,这也不会很有用。








除非有明确的目的,否则你不应该做任何事情。 想象一下有两个一切都是一样的平行的世界,除了你正在考虑做的事情:这些世界将会有什么不同? 这种不同值得花力气去做那件事情吗。

如果你没有明确的目的,而只是因为其他人都这样做,或者每个人都说这样做很重要,你才做这件事,那么对你来说可能没有真正的收益,因此你可能无法从中得到任何东西; 或者对你来说,可能有潜在的收益,但由于你没有目的,你的做法可能无助于实现这个收益。


如果你参与了项目选择和启动,你应该确保关注的是收益和需要解决的问题,而不是那些实现这些目标的产品本身。 典型的例子是电梯制造商,他们过去常常接受有关电梯速度的投诉,因此开展了多个项目以提高电梯的速度,但没有取得圆满成功。 直到他们决定关注问题(人们的无聊或不适)而不是看似自然的解决方案(更快的电梯)。 最终他们为电梯安装了镜子,简单而低成本的解决了问题。

请记住,项目管理主要关注的是把事情做正确,而项目组合管理关注的是做正确的事情。 你如何把一个项目开展好,可能无关紧要; 但是如果你做错了项目,将会一无所获。 这就是说做任何事情需要有一个目的。















在许多项目中,通常会有一个非常长的状态报告。 基于项目通用原则(NUP),我们应该问自己报告的目的是什么,以及我们如何能够实现这一目的,而不是关注其他人可能在做什么。

在许多情况下,这使得我们会准备了一份非常简单的、利益相关方会真正阅读和理解的单页报告,而不是一份长报告。 这是对目的的关注。

但是,如果你只准备一页长度的报告,有些人可能会就此不满,并认为你没有的提供“适当的”监控系统。 在实践中,这为你创建了第二个目的(除了第一个目的,帮助利益相关方了解项目的状态),为了满足这一目的,你可以简单地创建非常长的第二类报告。 但是,你不会将其与第一个报告混合,因为这两个目的不同。


准备诸如商业论证和项目章程之类的文件对于大多数人来说通常是无聊的和盲目的,对于大多数人来说又是官僚主义的必需品。而这些文件又适用于大多数项目。 如果你试图找到一个“模板”并进行填充,那么工作就浪费掉了;你可以检查这些文档的真实目的,看看它们是否以及应该如何在您的项目中发挥作用,然后以你喜欢的任何方式来准备文档,只是为了满足“这将会是正确的文档”这个目的。

当你在考虑如何准备这些文档以满足其目的的时候,你可能会想不到每一个场景,可能会遗漏某些内容。 为避免这种情况,您可以查看PRINCE2®,PMBOK®Guide,P3.express和DSDM®等建议的资源,然后根据目的评估这些建议。




世界是复杂而混乱的,但我们的模型是世界某些部分抽象近似的表达,因此它们可以很简单。 另一方面,简单系统通常效果更好,因为我们可以专注于主要想法。






对于一个项目来说,临时的方法需要消耗太多的精力和资源,并且总是存在遗漏一些必要元素的风险。 简化必须完成的工作的最佳方法是使用可重复的元素,并且最好可以重复循环使用。



  • 首先,你可以创建一个所有标准的清单,这是一种计划形式。

  • 项目通用原则六(NUP6)的建议是尝试对其进行归纳:项目中是否还有其他类似的可交付成果?在这种情况下,为该类可交付成果准备一份通用质量检查单,并将其用于所有质量检查单。如果有不同的地方,请保留通用清单,并为各个单独的可交付成果添加一些额外检查项。这样你就有了可重复的质量检查单。

  • 一旦为各种类型的可交付成果准备了通用检查单,你可能会发现在它们之间重复的元素,这表明需要为它们准备一个虚拟的上级父类别。在这种情况下,你可以提取它们并将它们放在上一级的检查表中,而不是在通用检查单中重复所有这些的项目。最后,你可能会为整个项目提供一个通用的检查清单。 Scrum中对“完成”的定义是使用项目级检查单来提高质量的一个例子(可能包括其他内容)。通过这样做,每个可交付成果将属于一个类别层次,应该能够满足所有类别清单中出现的项目。






除了可用于技术活动的可重复工作流之外,你还可以为项目管理活动提供可重复的元素。 PMBOK®指南,PRINCE2®和DSDM®中的流程,P3.express中的活动以及Scrum中的事件都是这个概念的示例。


拥有可重复元素对于管理项目来说是有帮助的。 通过将它们置于可重复的周期中,可以使管理项目变得容易。 这些周期大大简化了参与项目管理和领导的人员的日常活动。 用于具有多个阶段项目的PMBOK®指南中的过程组周期,PRINCE2®中的阶段,P3.express中的每日,每周和每月周期,DSDM®中的迭代和时间框以及Scrum中的Sprint都是这个概念示例。短的周期比长的周期更容易理解和使用; 例如,与PMBOK®指南的阶段相比,Scrum中的Sprint更容易理解和使用。 但是,太短的周期可能不足以支持某些类型的项目,解决方案可能是使用多个周期,例如DSDM®将较短时间盒周期与较长的迭代周期一起使用,或者P3.express中使用每日,每周和每月周期。


使用一个方法论或一个框架来开展项目是可重复元素的另一种使用。 这可以是现存的体系,如PRINCE2®,,DSDM®或Scrum,也可以是你自己定制或构建的体系。 但是,从一个现有方法开始,并根据你的需要进行调整,而不是从头开始构建,通常是一个更好的主意。

任何可重复的元素都是抽象的,需要定制才能使其适应现实世界。 然而,有一系列的抽象和定制需求:小的,相对具体的质量检查单处于这个系列的一端,具有少量的抽象和剪裁需求;而方法论的另一端,具有较高的定制需求。 你应该始终注意剪裁的需求,否则,可重复元素将无法正确的满足你的需求。


NUPP er en samling av nesten universelle prinsipper for prosjekter: de vi vil lykkes med å følge i alle prosjekter, uavhengig av metodene og tilnærmingene vi bruker for å maksimere vår suksess.

Hver av de tilgjengelige ressursene og metodene for å kjøre prosjekter er avhengig av enkelte av disse NUP’ene (nesten universelle prinsipper). Imidlertid må følgende punkter tas i betraktning:

  • Det er vanligvis ikke alle som er like relevante, og det vil være nyttig for utøvere å vurdere alle NUPer i stedet for en delmengde.
  • De underliggende prinsippene er vanligvis ikke beskrevet godt nok i de tilgjengelige ressurser og metoder, og de fleste utøvere er så engasjert i praktiske detaljer at de glemmer prinsipper og gjør ting som ikke er kompatible med dem.

NUPP er kompatibel med alle de store metoder, systemer, ressurser og rammeverk som PRINCE2®, PMBOK® Guide,, PM², DSDM®, XP og Scrum. Det kan imidlertid være lite kompatibilitet med visse tolkninger av disse rammeverkene, og det er her NUPP forsøker å oppmuntre utøvere til å revurdere sine tolkninger.

NUPP er en samling av følgende NUP:


Foretrekke resultater og sannheter, fremfor gruppetilknytninger

Vi har alle en naturlig tendens til å tilhøre grupper, en tendens som ofte går utover sin grunnleggende form, skaper sterke tilknytninger og forårsaker problemer. Vi mister mye mer enn vi får på grunn av tilknytning. Vi kan bli mer profesjonelle og effektive eksperter hvis vi ikke begrenser vår identitet og preferanser til bestemte grupper.

Eksempel: Agile vs vannfall

En gruppe svært entusiastiske mennesker som var modige nok til å prøve adaptive utviklingsmetoder i IT-utvikling på et tidspunkt da normen skulle bruke prediktive tilnærminger, kom sammen og kalte deres tilnærming “Agile”. Det er fortsatt mange entusiastiske og resultatorienterte mennesker i Agile-samfunnet, men dessverre er det også noen mennesker i dette samfunnet som gjør Agile til en kult, og anser alle utenforstående som fiender. Dette forårsaker problemer på flere måter, inkludert følgende:

  • Det begrenser dem i å kunne lære av noen utenfor sin gruppe
  • Det fraråder utenforstående å lære av dem
  • Det å tilhøre gruppen blir ofte viktigere enn det virkelige formålet, noe som igjen forhindrer at mange av medlemmene lærer den virkelige betydningen av Agility

Dette problemet kan bli betydelig redusert, hvis ikke fjernet, ved å bruke “Agile” bare som en etikett som refererer til en utviklingsmetode snarere enn som et fellesskap med medlemmer; og ved å ha folk som betrakter seg som skapere, problemløsere og ledere, som ser Agile rett og slett som et av flere verktøy, fremfor som deres identitet.

Det er ingen Agile-vannfall krig for ekte fagfolk.

Eksempel: PRINCE2® vs PMBOK® Guide

Det er mange fagfolk i samfunnet som knytter seg til enten PRINCE2® eller PMBOK® Guide (vanligvis på grunn av deres geografiske plassering) og er ikke kjent med den andre. Vi kan alle ha preferanser mot bestemte rammeverk og ressurser, men ikke som vår identitet, og enda viktigere, må vi gjøre oss kjent med dem alle for å utvide vårt perspektiv og våre valg.

Den virkelige profesjonelle er åpen for alle ideer, ser etter dem, lærer om dem, og bruker dem når det trengs, uten gruppetilknytning.

Eksempel: Kontinuerlig læring

Tilknytninger tilfredsstiller personen på grunn av følelsen av tilhørighet som oppstår, men det setter ikke et press på å lære. Noen ganger blir man til og med oppmuntret til å ikke lære av frykt for å miste dem. Når du er en fri person, en ekspert uten tilknytning, må du fylle inn gapet med læring: med kontinuerlig læring.

Det vi tror på i dag er ikke sannheten. Det er bare vår beste forståelse så langt, som må forbedres når vi fortsetter. Det er noe galt om ens ideer er akkurat det samme som for noen år siden. Dette er også tilfelle for NUPP: Hvis du kommer tilbake etter noen år og ser nøyaktig det samme, bør du bli mistenksom.

Eksempel: Åpenhet

Når du diskuterer med noen, må du sørge for at du sikter mot ideen, og ikke personen. Dette bidrar til mindre konflikter. På samme måte, når noen diskuterer med deg, prøv å ikke tolke det som en krig mot deg, men heller en diskusjon av ideene dine, og hold deg åpen for det. Ikke lytt for å kunne svare, lytt for å kunne forstå; og for å kunne jobbe med den andre personen for å forbedre ideen.

Noen mennesker kan med vilje ha deg som person som mål i stedet for ideen, i så fall bør du hjelpe dem med å fokusere på ideen i stedet for på deg, og forsøk å holde dette fokuset gjennom hele samtalen.


Bevare og optimalisere energi og ressurser

Ressurser er begrensede. Ressurser som er tilgjengelige for prosjektet ditt er begrensede, og det er også den mentale kapasiteten du må bruke for å gjøre gode beslutninger. Du bør bevare og optimalisere disse ressursene for deg selv og for prosjektet, og hjelpe andre team medlemmer til å gjøre det samme.

Eksempel: 80/20 regelen

En stor del av de potensielle gevinstene ved prosjektledelse kan oppnås ved å utnytte en liten del av innsatsen. I de fleste tilfeller er målet om å nå 100% av gevinstene svært kostbart og uberettiget. Du bør vurdere denne regelen i alt du gjør, og oppfordre andre til å gjøre det samme.

Eksempel: Beslutningsudyktighet

Vi bruker mental energi for å ta alle typer beslutninger, og også for å uttrykke viljestyrke. Hvis du bruker mye av denne energien til å gjøre unødvendige eller ubetydelige beslutninger, vil du ha mindre energi for de viktige avgjørelsene, noe som kan føre til dårlige resultater i prosjektet ditt. Dette er en av grunnene til at du bør unngå detaljstyring (“manage by exception” prinsippet i PRINCE2®).

Konflikter som handler om ideer kan være nyttige, men de som handler om mennesker, er vanligvis skadelige for prosjektet, og en av konsekvensene er at det drenerer den mentale energien til team medlemmene. Hvis du oppdager en slik konflikt, bør du gjøre ditt beste for å finne rot-årsaken, og løse den.

Eksempel: Ta vare på deg selv!

De avgjørelsene du tar og viljestyrken du uttrykker, bruker av din mentale energi. På den annen side blir denne energien fylt opp når du sover og spiser riktig. Så, ta godt vare på deg selv: sørg for at du får nok søvn og hvile, og spis godt. Hvis du har skadelige vaner eller problemer med søvn, trenger du ikke å håndtere det alene; det er mange spesialister som kan hjelpe deg med å løse slike problemer. Fysisk aktivitet kan også bidra med tilføring av energi, selv om studier ennå ikke er avgjørende i denne saken.

Prøv å oppmuntre dine team medlemmer til å gjøre det samme som du gjør. Først må du sørge for at de jobber i bærekraftig tempo, og uten for mye overtid. Deretter, hvis du har valget, prøv å tilby energisk, sunn mat, snacks og drinker i løpet av arbeidstiden.

Eksempel: Jobb-Privatliv balansen

Mange av oss elsker det vi gjør på jobb, men det er fortsatt ikke alt vi trenger å ha i livet. På samme måte som du optimaliserer arbeidet ditt, bør du planlegge og implementere ideer i ditt personlige liv, på måter som gjør det til et godt og lykkelig liv. Når du er lykkeligere, kan du bli mer vellykket på jobb også. Hvis du har muligheten bør du prøve å oppmuntre team medlemmene til å gjøre det samme.

Eksempel: Motivasjon

Motivasjon er et komplekst konsept. Det er mange interessante og nyttige artikler og ressurser tilgjengelig om emnet, så vel som en del uvitenskapelige. Likevel bør du lære om det og bruke det kontinuerlig, da det øker teamets mentale energi og muligheten for å oppnå bedre resultater for prosjektet.

Motivasjon kan være så enkelt som å la folk få vite at du anerkjenner deres gode arbeid med et smil eller et “takk for hjelpen”. Men du må være forsiktig, fordi mange av de vanlige formene for motivasjon, for eksempel små pengemessige belønninger, har en negativ effekt.

Eksempel: Samarbeid og teamwork

Mennesker som samarbeider skaper ofte bedre resultater, men enda viktigere er at mennesker er sosiale og liker å være en del av en gruppe. Hvis du kan fjerne de negative aspektene av samarbeid og skape et hyggeligere miljø, vil medarbeiderne i prosjektet trives bedre.

Du bør imidlertid være oppmerksom på at folk er forskjellige, og noen trenger mer fokusert tid alene, både for trivselen sin del, men også for effektivitetens del.

Eksempel: Felles kultur

Det er en tendens blant ulike interessenter å opprette adskilt grupper/team og dermed forårsake spenning med andre team; for eksempel folk som er fokusert på forretningsaspektet av prosjektet vs. personer som bygger produktet. Denne spenningen bruker mye energi fra begge sider, noe som er en av grunnene til at vi skal forsøke å bygge en felles kultur, hvor alle jobber sammen mot det samme målet.

Eksempel: Kollektiv intelligens

Når et stort antall mennesker med variert bakgrunn og erfaring kommer sammen og arbeider i et felles miljø, er det potensiale for svært gode resultater, samt nye ideer og løsninger som er langt bedre enn de som kommer fra en enkelt fagperson.

Hvis du har muligheten, kan du bruke det regelmessig til å spørre gruppemedlemmer for å hjelpe deg med å løse vanskelige problemer i prosjektet. Ved siden av muligheten for å få gode resultater, tillater det også team medlemmer å vite at deres meninger blir verdsatt, og at de spiller en viktig rolle i prosjektet, noe som igjen øker deres energinivå. Aktivitet # 26 av er et eksempel på bruk av kollektiv intelligens i prosjekter.

Eksempel: Prosjekt Fasilitator

Hvis du er prosjektleder, er de fleste oppgavene dine av en fasiliterende art (eller i det minste bør være det). På den annen side kan du se at team medlemmene har hatt dårlige erfaringer med prosjektledere tidligere, og at disse opplevelsene har innvirkning på deres forhold til deg. En del av deres energi brukes til å analysere oppførselen din for potensielle trusler i stedet for å stole på deg. I så fall kan du endre tittelen fra prosjektleder til Prosjekt Fasilitator. Tross alt, det er det du egentlig gjør i prosjektet.


Alltid være proaktiv!

Det er en naturlig tendens i oss mennesker til å være reaktiv. Det kan hjelpe oss med å kaste bort energi på oppgaver eller forhold som er ubetydelige, eller det kan være en fordel når vi arbeider med et område der vi er helt inkompetente. Slike situasjonene er forskjellige fra våre prosjekter, og her kan vi få bedre resultater ved å være mer proaktive.

Eksempel: Planlegging

Hvis du vil kjøre til et nytt sted, og du er sen, kan du begynne å kjøre umiddelbart for å “spare tid” og håndtere mulige problemer når de oppstår. Den proaktive tilnærmingen er å ta litt tid i starten og bruke navigasjonssystemet for å gi deg den raskeste ruten basert på trafikken og mulige ulykker og blokkeringer og deretter kjøre. Du bruker litt tid i starten før du kjører, for å unngå problemer senere og dermed spare tid til slutt.

I motsetning til hva noen mennesker tenker på Agile-prosjekter, er planlegging alltid nødvendig, og det handler bare om typen og detaljnivået i planene. Planlegging før utførelse er en proaktiv tilnærming.

Husk sitatet: Gi meg seks timer til å hugge ned et tre og jeg vil tilbringe de fire første til å kvesse øksen.

Hvis det er et prediktivt prosjekt, kan du tilbringe 4 timer å kvesse øksen din, fordi du er sikker på at du skal hugge ned et tre. I et Agile-prosjekt er du ikke sikker på om du skal hugge ned et tre, samle ødelagte grener, grave etter kull eller noe annet. Likevel trenger du fortsatt å ha en generell forberedelse for alle aktivitetene (for eksempel finne ut hvor nærmeste maskinvarebutikk er), og gjøre en rekke forberedelser når du skal fokusere på en bestemt løsning; det er planlegging.

Eksempel: Planlegge planleggingen

Å planlegge måten vi skal gjennomføre prosjektet på, er en proaktiv tilnærming. Denne proaktiviteten kan til og med utvides ved å planlegge måten vi skal planlegge gjennomføringen av; det er konseptet til styringsplanen for PMBOK® Guide, styringsstrategier for PRINCE2®, og tilnærminger i DSDM®.

Eksempel: Kontinuerlig planlegging

Virkeligheten stemmer sjelden overens med det vi har planlagt, og det er OK - men vi må kontinuerlig tilpasse våre planer for å sikre at de blir realistiske og praktiske. Vi bør gjøre det så snart det er nødvendig med tilpasning, og ikke når vi får problemer. Det er en proaktiv tilnærming.

Eksempel: Risikostyring

Hele konseptet med risikostyring er basert på proaktivitet: når vi står overfor usikre hendelser, i stedet for å vente på å se hva som skjer og deretter reagere på dem, tenker vi på muligheter og konsekvenser, vurderer tiltak, og sannsynligvis gjør noe med det før det skjer.

Legg merke til at det vi gjør i prosjekter noen gang handler om folks liv, og i slike tilfeller vil risikostyring være en helt sentral aktivitet.

Eksempel: Definere roller og ansvar

Du kan la prosjektgruppemedlemmene jobbe uten klare roller og ansvar, og før eller senere kommer en form for roller og ansvar fram, men det er for tidkrevende og vil mest sannsynlig ikke fungere så bra. Den proaktive tilnærmingen er å definere roller og ansvar tidlig og tilpasse etter behov. Dette gjør arbeidet lettere for alle, og de kan fokusere på å produsere noe, i stedet for å bestemme hvem som gjør hva.

Antallet og variasjonen av roller er avhengig av prosjektets type og størrelse; Det kan være en enkel definisjon som den i Scrum, noe moderat som det i, eller noe omfattende som i DSDM® og PRINCE2®. Men ikke glem at rollebeskrivelsene i disse metodene bare handler om ledelsesaktiviteter, og at du alltid må legge til rollebeskrivelser for tekniske aspekter også.

Eksempel: Valgmuligheter

Skal du lukke prosjektet for tidlig eller fortsette med det?

Det er sjelden bare to valg, selv om det kan virke slik. Du må ha en proaktiv tilnærming og vurdere alle dine valg før du tar en beslutning. Kanskje du kan re-scope prosjektet; kanskje du kan stoppe det til noe annet blir klart; eller kanskje du kan endre prosjektets tilnærming (f.eks. outsourcing), etc.

Eksempel: Kritisk tenking

Vi lever alle med våre antagelser og virkelighetsoppfatninger som hjelper oss å overleve på den ene siden, men som på den andre siden kan lure oss til å gjøre dårlige beslutninger. Når det gjelder å ta viktige beslutninger om prosjektet, er det best å pause en stund og vurdere alle forutsetninger som kan påvirke vår beslutning.

Som referanse kan du bruke listen over kognitive forstyrrelser fra Wikipedia:

Det finnes til og med rammeverk for beslutningsprosesser som du kan bruke til å ta bedre beslutninger. I begynnelsen kan det være distraherende og til og med irriterende å bruke dem, men snart blir du vant til dem, og kan dra nytte av dem uten mye bevisst innsats.

Eksempel: Åpenhet

Vi liker ikke å være forsinket i prosjektet eller ha noen annen type problem, men det betyr ikke at vi skal gjemme det. Du bør være åpen om problemene og la interessentene vite om dem, fordi noen av dem kan være i stand til å hjelpe deg, og i tillegg vil de få vite om problemene og deres konsekvenser før eller senere, og noen av dem kan kreve korrektive tiltak fra deres side (f.eks. for å godta den negative konsekvensen).

Eksempel: Kommunisere effektivt

Det vil skje at du sender statusrapporter til dine interessenter, og at tilbakemeldingene uteblir. Du kan tro at alt er bra bare fordi det ikke er noen tilbakemelding, selv om det kanskje ikke er slik. Du må være proaktiv og se om de virkelig har satt seg inn i statusen, og om statusrapporten har tjent hensikten, og bruk eventuelle tilbakemeldinger for å justere kommunikasjonsmetodene dine.

Eksempel: Ta ansvar

Det er lett å klandre andre for dårlige resultater. For eksempel vil du kanskje at organisasjonen skal gi deg full autoritet til å endre alt via prosjektet og gjøre det perfekt, men de gjør det ikke, og som et resultat svikter prosjektet. Dette er ikke en proaktiv tilnærming.

Den proaktive tilnærmingen er å ta ansvar og gjøre alt du kan innenfor rammebetingelsene som er satt. Du kan ikke forvente at organisasjonen fullt ut stoler på deg og gir deg alt i håp om å få gode resultater, spesielt når de har sett så mange mislykkede prosjekter. Det du må gjøre er å gjøre en liten forbedring innenfor de rammebetingelsene som er satt, bruk det for å få litt tillit, noen flere ressurser og litt mer toleranse for feil og utbedringer, og bruk deretter det for en litt større forbedring og fortsett slik til du når målet.


Husk at en kjede kun er så sterk som det svakeste ledd

Det er ulike domener i prosjekter, og de trenger alle oppmerksomhet. Vi må ha et helhetlig perspektiv på prosjektet. Å være oppmerksom på et tilsynelatende viktig domene (f.eks. tid) er ikke nok, fordi alle domener virker sammen, og de fungerer ikke skikkelig med mindre de alle får tilstrekkelig oppmerksomhet.

Eksempel: Alt for å rekke tidsfristen!

La oss si at du bygger noe for de olympiske leker. Det har en absolutt deadline, noe som gjør tidsstyringen svært viktig. Men er det riktig å bare tenke på tid?

Hva om kvaliteten er så lav at det nødvendiggjør gjentagende arbeid etter en stund. Det ville påvirke tiden, så dermed er både tid og kvalitet viktig. Du kan ha en fancy hage som er beskrevet i den opprinnelige definisjonen av prosjektet, men du vet at hvis det ikke er nok tid, kan du hoppe over det og bare dekke det til med gress, så lenge du har vurdert denne muligheten i tide og er forberedt på den. Dermed er håndtering av omfang også viktig. Nå har vi omfang, tid og kvalitet som domener i sentrum av vår oppmerksomhet.

Etter hvert som du opparbeider deg erfaring, legger du merke til at hvert enkelt domene i prosjektet bidrar til tidsstyring, og du kan ikke møte fristen med et akseptabelt nivå av sikkerhet, med mindre du tar hensyn til alle domener.

Eksempel: Cherry picking

Når folk står overfor en rekke metoder, begynner de ofte å favorisere noen av dem og lage en blanding av alt som synes interessant fra forskjellige rammeverk. Dette fungerer vanligvis ikke, fordi elementene ikke virker isolert og må være kompatible med hverandre. Eventuelle tillegg eller endringer i et rammeverk bør gjøres fra et helhetlig synspunkt.

Derfor ser vi noen ganger motstridende elementer i forskjellige metoder. Noe fungerer godt i ett system, og det motsatte virker godt i et annet system. Det enkelte elementet er ikke riktig eller feil på egen hånd.

Den sikreste tilnærmingen er å velge en metodikk for prosjektet, skreddersy det og legge til nye elementer ved å vurdere konsistensen av hele systemet.

Eksempel: Anti-prosess tilnærming

En av de beste tingene Agile metoder har gjort er å trekke oppmerksomhet på menneskelige aspekter. Agile Manifesto gir mer verdi til enkeltpersoner og samspill, i forhold til prosesser og verktøy, selv om dette kanskje ikke er en rettferdig sammenligning. Nesten alle metoder sier at menneskelige aspekter er viktige, og den virkelige forskjellen med Agile metoder er at menneskelige aspekter er en integrert del av deres prosesser, snarere enn et forslag. Så, det handler ikke om konkurranse mellom menneskelige aspekter og prosesser, men snarere om hvordan menneskelige aspekter sees på i systemet.

Det er ingen tvil om at noen mennesker prøver å erstatte de menneskelige aspektene ved å ha mer sofistikerte prosesser, men det er et misgrep. Selv det omvendte eksisterer: folk som prøver å erstatte prosesser med menneskelige aspekter, som heller ikke fungerer så bra.

Eksempel: Dette er alle domenene du trenger

Når du tenker på domener, bør du være påpasselig så du ikke går glipp av noen. Men, hva er egentlig de mest kjente domenene? Hvis du sjekker de grunnleggende rammeverkene, vil du finne forskjellige svar; og likevel er ingen av dem den hele og fulle sannheten.

PRINCE2®-temaer er domener, men det er bare de domenene som spiller en nøkkelrolle i metodikken. De andre domenene er bare underforstått.

PMBOK® Guide er ikke en metodikk og kan formulere det mye bedre med de ti kunnskapsområdene. Imidlertid er disse tolkninger av alle domener basert på PMBOK®Guides perspektiv på prosjektet, i stedet for en nøytral (ikke at det nødvendigvis er et nøytralt perspektiv). For eksempel får menneskelige aspekter ikke mye oppmerksomhet i PMBOK® Guide.

En god kilde til informasjon om domenene er ICB. Det handler imidlertid ikke om domenene, men om kompetansene som kreves i prosjektet. De har ikke et en-til-en-forhold med domenene, men det hjelper mye å identifisere dem.

Det er ingen liste over domener i NUPP, hovedsakelig fordi det er et meta-system i stedet for et system, og også fordi kategoriseringen av domenene avhenger av typen prosjekt og dets miljø. Et rutinemessig byggeprosjekt kan for eksempel kreve et annet perspektiv enn et kreativt forskningsprosjekt.


Ikke gjør noe uten et klart formål

Du bør ikke gjøre noe med mindre det har et klart formål. Tenk deg to parallelle verdener hvor alt er det samme bortsett fra det du vurderer å gjøre: Hvor annerledes ville disse verdenene være? Er forskjellen verdt innsatsen for å gjøre det?

Hvis du ikke har en klar hensikt i tankene og bare gjør noe fordi alle andre gjør det, eller alle sier at det er viktig å gjøre det, da

  • Kan det ikke ha en reell fordel i ditt tilfelle, og derfor kan du ikke få noe ut av det. eller
  • Det kan fortsatt ha potensielle fordeler i ditt tilfelle, men fordi du ikke har formålet i fokus, kan det ikke hjelpe deg med å realisere fordelene.

Eksempel: Porteføljer og programmer

Hvis du er involvert i utvelgelse og oppstart av prosjekter, bør du sørge for at du fokuserer på fordelene og problemene som må løses, i stedet for produktet som skal realisere disse tingene. Det klassiske eksempelet er produsenten av heiser som pleide å motta klager om hastigheten på sine heiser, og så hadde de kjørt flere prosjekter for å øke hastigheten uten full suksess. Det fortsatte inntil de bestemte seg for å fokusere på problemet (folks kjedsomhet eller ubehag) i stedet for den “naturlige” løsningen (raskere heiser). Resultatet var at de satt opp speil i heisene, og det løste problemet enkelt og billig.

Husk at prosjektledelsen handler om å gjøre ting riktig, mens porteføljestyring handler om å gjøre de riktige tingene. Det spiller ingen rolle hvor godt du kjører prosjektene dine; det vil ikke fungere bra hvis du gjør feil prosjekter. Det handler om å ha et formål.

Eksempel: Prosjektet som helhet

Fleksibiliteten i selve produktet varierer mellom prosjekter. I enkelte IT-utviklingsprosjekter er produktet helt fleksibelt, og den endelige formen avhenger av tilbakemeldingen som vil bli generert av inkrementene i produktet underveis i prosjektet, noe som krever en adaptiv (Agile) tilnærming. Dette er praktisk sett en kombinasjon av portefølje-, program- og prosjekt, og krever maksimal oppmerksomhet til det endelige målet. Det er en god idé å dokumentere hensikten og ha den lett tilgjengelig. Det er et av formålene med “produktvisjon”, som brukt i noen Scrum-prosjekter. Oppmerksomheten på forretningsverdi i Agile-prosjektene er deres måte å sikre tilpasning med formål.

I andre typer prosjekter hvor produktet er relativt fast og det finnes andre mekanismer for å sikre at det identifiserte produktet vil tilfredsstille formålet, er det mulig for prosjektgruppemedlemmene å skifte en stor del av fokuset fra formålet til selve produktet (dermed prinsippet om fokus på produkter “PRINCE2®), men oppmerksomhet mot formålet er fortsatt nødvendig for å sikre at det som blir bygget vil tilfredsstille formålet, som kan gjøres ved å sammenligne de prognostiserte fordelene med de forventede fordelene ( dermed prinsippet om “continued business justification” og “business case” temaet i PRINCE2®).

Når et prosjekt kjøres for en ekstern klient, vil klienten ha sin egen hensikt for prosjektet, og bedriften din vil ha en annen hensikt. Du bør forstå og bruke begge disse for å virkelig lykkes.

Eksempel: Prosjektoppfølging

Fokus på det overordnede formålet er nødvendig, men det kan være for abstrakt for mange av de daglige bruksområder. Derfor er det nødvendig med et hierarki av drivere for å gjøre det mer praktisk. For det første defineres begrunnelsen og fordelene ved prosjektet basert på det endelige formål, og da vil du ha eksplisitte og implisitte mål for prosjektvariabler (f.eks. tid, kostnad og kvalitet) for å tilfredsstille begrunnelsen, som igjen vil tilfredsstille det overordnede formål. Disse er lavere nivåer som er nyttige for mange av våre daglige oppgaver.

Når det gjelder oppfølging, vil overvåking av de daglige oppgavene i prosjektet bli gjort ved å bruke det laveste nivået av variabler, fordi det kanskje ikke er mulig å spore det endelige målet. I dette tilfellet bør du fortsatt ha formålet med deg i tankene: hva er formålet med overvåking?

Et normalt og akseptabelt svar er å se om vi er i henhold til plan, og hvis ikke, må vi initiere aksjoner for å bringe oss tilbake på planen eller justere målene og se om det fortsatt kan tilfredsstille det endelige målet. Våre målinger bør derfor kunne hjelpe med denne vurderingen, og de riktige målingene er prognoser for variablene ved ferdigstillelse; for eksempel når kan vi fullføre prosjektet? Hvor mye penger trenger vi for å fullføre prosjektet?

Alle andre målinger, for eksempel de planlagte og faktiske verdiene til dags dato, er bare midlertidige verdier som du trenger for å beregne prognosene, ikke de endelige verdiene du bruker til styringsformål.

Eksempel: Dokumenter

Uansett hvilken utviklingsmetode du bruker i prosjektet, er planlegging alltid nødvendig. Det viktige spørsmålet er detaljnivået i hver type plan. Hvis det ikke er nok detalj i planen, vil planen ikke kunne bidra med nok, og gjennomføringen av prosjektet vil være basert på ad hoc-beslutninger snarere enn integrerte og helhetlige. På den annen side prøver mange mennesker å være påpasselige og legge for mye detalj i planen, noe som gjør det for vanskelig å forberede og vedlikeholde, og dermed blir planen for rigid for prosjektets usikkerhet. Som et resultat blir planen urealistisk og ubrukelig.

Den beste måten å bestemme om detaljnivået er riktig, er å ha en hensikt i tankene for hvert element i planen. Hvis du for eksempel vurderer å legge til ressurser til planen, bør du ha en hensikt for det: Hvordan skal du bruke den? Hvordan vil det hjelpe prosjektet? Hvor mye innsats vil det ta? Og er det verdt det?

Det handler noen ganger om å avgjøre om du vil ha et visst element i dine planer, og noen ganger om hvordan du vil planlegge eller forberede noe. Enten det er et business case, et prosjekts charter eller en rapport: Du bør fortsatt spørre deg selv hvorfor du forbereder dokumentet og hvordan det kan hjelpe prosjektet.

Å lete etter en “mal” er det motsatte av å gjøre noe basert på et formål.

Eksempel: Statusrapportering

Det er vanlig å ha veldig lange statusrapporter i mange prosjekter. Basert på denne NUP, bør vi spørre oss hva formålet med rapporten er og hvordan vi kan oppnå det formålet, uansett hva de fleste andre velger å gjøre.

Det kan ofte være tilstrekkelig å lage enkle en-siders rapporter som interessentene dine virkelig leser og forstår i stedet for lange rapporter. Det handler om å være oppmerksom på formålet med det du gjør.

Hvis du forbereder en-siders rapporter, kan enkelte mennesker motsette seg din fremgangsmåte og tenke at du ikke har et “riktig” overvåkingssystem på plass. I praksis oppretter dette et annet formål for deg (foruten det første formålet, som hjelper interessenter å forstå statusen til prosjektet), og for å tilfredsstille det, kan du bare lage en annen type rapport som er veldig lang. Du vil imidlertid ikke blande det med den første rapporten, fordi disse to formålene ikke er de samme.

Eksempel: Business case og Prosjekt charter

Forberedelse av dokumenter som et business case og et prosjekt charter er vanligvis en kjedelig, fruktløs, byråkratisk nødvendighet for de fleste av oss, mens disse dokumentene alle har gyldige formål som gjelder for de fleste prosjekter. Hvis du prøver å finne en “mal” og fyller den inn, er arbeidet bare bortkastet; mens hvis du i stedet kan sjekke den virkelige hensikten med disse dokumentene, se om og hvordan de kan være nyttige i prosjektet ditt, og utarbeide dokumentet på en slik måte du liker, for å tilfredsstille formålene: det vil være det riktige dokumentet for ditt prosjekt.

Det kan være vanskelig å tenke på alle scenarier og alle områder som bør være en del av slike grunnleggende styringsdokumenter, og kanskje mangler du noe viktig. For å unngå at du mangler noe viktig, kan du sjekke for å se hvilke ressurser som inngår i PRINCE2®, PMBOK® Guide, og DSDM®suggest, og deretter vurdere disse forslagene basert på formålet.

Eksempel: Prosjektevaluering

Selv om prosjektet har et bestemt formål, og vi kan vurdere dette formålet gjennom hele prosjektet, er realiseringen av formålet hovedsakelig basert på prognoser i prosjektet. Vi bør imidlertid ikke glemme dette når prosjektet er ferdig. Det er viktig å sjekke realiseringen av målene etter at prosjektet er ferdig, fordi

  • vi kan se hvordan de endelige målene ble nådd og lære av det for fremtidige prosjekter, og
  • noen ganger blir målene nådd bare hvis vi utfører noen ekstra oppgaver etter prosjektets gjennomføring, og det å forstå behovet for disse ekstra oppgavene krever overvåking.

Prosjektevaluering er en viktig del av å være målfokusert. Det er hovedsakelig ansvaret for program- og porteføljestyringssystemer, og fordi de fleste selskaper ikke har slike systemer tilgjengelig, blir denne delen vanligvis forsømt. Derfor legger metoder som og DSDM® denne delen til i sine prosjektledelsesmetoder.

Eksempel: Enkelhet

Verden er kompleks og kaotisk, men våre modeller er kun abstrakte tilnærminger som reflekterer deler av verden, og dermed kan de være for enkle. På den annen side fungerer enkle systemer vanligvis bedre, fordi vi kan være fokusert på hovedideen.

Mange av oss prøver å få bedre resultater ved å legge til kompleksitet i våre systemer, i håp om at det vil samsvare med verdens kompleksitet, selv om det i praksis gjør systemet vanskelig å jobbe med og vanligvis blokkerer oss fra å tilfredsstille formålet.

Eksempel: Skreddersøm

Et stykke programvare for streaming av musikk har en helt annen tilstand enn den som skal brukes til utstyr på et sykehus, eller fra et program som skal brukes i en satellitt hvor tanken er at det skal fungere tilfredsstillende i mange år uten å krasje. Det er stor forskjell på å bygge en sommer villa, sammenlignet med en brannstasjon eller et prosessanlegg.

Når du har formålet med deg i tankene, vil du bedre forstå hvordan du kan skreddersy systemene og artefaktene for de ulike prosjektene.


Bruk repeterbare elementer

En ad hoc-tilnærming til prosjektet tar for mye energi og ressurser, og du løper alltid en risiko for at du mangler noen av de nødvendige elementene. Den beste måten å angripe det som må gjøres er å bruke repeterbare elementer, og helst å ta dem i repeterbare sykluser.

Eksempel: Sjekklister for arbeid med kvalitet

En sjekkliste er et enkelt eksempel på et potensielt repeterbart element som mange bruker i sitt personlige og profesjonelle liv. Ta kvalitetskriterier for en prosjektleveranse, for eksempel:

  • Først kan du opprette en sjekkliste over alle kriterier, som er en form for planlegging.
  • Hva NUP6 anbefaler, er å forsøke å generalisere det: er det andre lignende leveranser i prosjektet? I så fall utarbeides en generell kvalitets sjekkliste for den kategorien av leveranser og gjenbruk den for alle disse. Hvis det er noen variasjoner, behold den generelle listen, og legg til noen ekstra elementer for de enkelte leveransene. Nå har du repeterbare sjekklister.
  • Når du har utarbeidet generiske sjekklister for ulike typer leveranser, kan du finne elementer som gjentar seg blant dem, noe som antyder en overordnet kategori for dem. I så fall kan du, i stedet for å gjenta elementene for alle de generelle sjekklistene, trekke dem ut og legge dem i en overordnet sjekkliste. Til slutt vil du sannsynligvis ha en generell sjekkliste for hele prosjektet. Scrums definisjon av ferdig («definition of done») er et eksempel på bruk av prosjekt sjekklister for kvalitet.

Ved å gjøre dette, blir et element i en overordnet sjekkliste repeterbart for alle leveranser under det, noe som sparer tid og energi i planlegging og utførelse.

Enda viktigere, når du gjør dette for ett prosjekt, kan du skreddersy og bruke det til alle lignende prosjekter i fremtiden, som er en repeterbar form for planlegging for flere prosjekter.

Eksempel: Prosesser og arbeidsflyt

Noen leveranser, eller mål knyttet til dem, inneholder visse trinn som kan bli standardisert og gjort repeterbare. For eksempel, hvis leveransen må utformes individuelt og godkjent, kan du forberede en enkel arbeidsflyt som beskriver alle trinnene, involverte personer og omtrentlige varigheter for disse, slik at du unngår problemer eller misforståelser. Du bør imidlertid være forsiktig med å ikke gjøre arbeidsflytene og prosessene for kompliserte eller for intensive i dokumentasjonen, da det vil få en negativ konsekvens. Alle som er involvert i prosjektet bør se arbeidsflyten og prosessene som noe som støtter sitt arbeid og gjør det lettere for dem, snarere enn som byråkratisk dokumentasjon som blokkerer det virkelige arbeid.

Agile prosjekter har repeterbare elementer i deres iterative utviklingstilnærming, hvor visse typer utviklingsaktiviteter gjentas for hver funksjon; f.eks den vanlige daglige rutinen i XP (eXtreme Programming): koble sammen (to og to), velg et element, utform det på en tavle, bygg testskriptene og koden, integrer koden etc.

I tillegg til de repeterbare arbeidsflytene som kan brukes til tekniske aktiviteter, kan du også ha repeterbare elementer for prosjektledelsesaktivitetene. Prosessene i PMBOK® Guide, PRINCE2® og DSDM®, aktivitetene i og hendelser i Scrum er eksempler på dette konseptet.

Eksempel: Sykluser

Å ha repeterbare elementer for å administrere prosjektet er nyttig. Dette kan gjøres enda enklere ved å sette dem i repeterbare sykluser. Disse syklusene forenkler de daglige aktivitetene til mennesker som er involvert i ledelsen av prosjektet. Sykluser av prosessgrupper i PMBOK® Guide når de brukes i et prosjekt med flere faser, trinn i PRINCE2®, daglige, ukentlige og månedlige sykluser i, iterasjoner og tidsbokser i DSDM® og Sprints in Scrum er alle eksempler på dette konseptet.

Kortere sykluser er lettere å forstå og bruke enn lengre; eksempelvis Sprints in Scrum i motsetning til fasene i henhold til PMBOK® Guide. Imidlertid kan sykluser som er for korte, ikke være nok til å støtte bestemte typer prosjekter, og løsningen kan være bruk av flere sykluser, for eksempel DSDM®s bruk av korte timeboks-sykluser sammen med lengre iterasjonssykluser eller ‘bruk av daglige, ukentlige og månedlige sykluser.

Eksempel: Metoder

Å ta i bruk en metodikk eller et rammeverk for å kjøre et prosjekt, er en annen bruk av repeterbare elementer. Dette kan være et eksisterende system som PRINCE2®,, DSDM® eller Scrum, eller en som du har tilpasset eller bygget deg selv. Det er normalt sett en bedre ide å starte med en av de eksisterende rammeverkene og tilpasse den til dine behov, enn å bygge det fra bunnen av.

Ethvert repeterbart element er abstrakt og trenger tilpasning for å passe med den virkelige verden. Det er et spekter av abstraksjon og behov for tilpasning. Små, relativt konkrete kvalitets sjekklister ligger i den ene enden av spekteret med minst mulig abstraksjon og behov for skreddersøm, mens metodologiene er i den andre enden, med det høyeste behovet for skreddersøm. Du bør alltid merke deg behovet for skreddersøm, ellers vil det repeterbare elementet ikke nødvendigvis passe til dine behov.


NUPP - гэта набор амаль універсальных праектных прынцыпаў, якім лепш прытрымлівацца ва ўсіх праектах, незалежна ад выкарыстоўваных метадалогій і падыходаў, калі мы хочам дамагчыся поспеху.

Кожны з вядомых падыходаў і метадаў для кіравання праектам абапіраецца на некаторыя з гэтых NUP (амаль універсальныя прынцыпы). Аднак, неабходна ўлічваць наступныя моманты:

  • Звычайна, выкарыстоўваюцца не ўсе прынцыпы, а для практыкаў было б карысна разгледзець усе NUP, а не паасобку.
  • Асноватворныя прынцыпы звычайна недастаткова растлумачаны ў падыходах і метадах, і большасць практыкаў настолькі захопленыя практычнымі дэталямі, што забываюць аб прынцыпах і робяць рэчы, якія несумяшчальныя з імі.

NUPP сумяшчальны з усімі асноўнымі метадамі, сістэмамі, рэсурсамі і асяроддзямі, такімі як PRINCE2®, PMBOK® Guide,, PM², DSDM®, XP і Scrum. Аднак, гэта можа быць несумяшчальна з пэўнымі інтэрпрэтацыямі гэтых сістэм, і менавіта тут NUPP спрабуе заахвоціць практыкаў перагледзець свае інтэрпрэтацыі.

NUPP - гэта калекцыя наступных NUP:


выбірай вынікі і праўду, а не прыхільнасці

Ва ўсіх нас ёсць натуральнае імкненне належаць да груп, імкненне, якое часцяком выходзіць за рамкі першапачатковай формы, стварае трывалыя сувязі і выклікае праблемы. З-за прыхільнасцяў, мы губляем нашмат больш, чым знаходзім. Не абмяжоўваючы сваю ідэнтычнасць і погляды прыхільнасцямі, мы можам дамагчыся больш, як прафесіяналы.

Прыклад: Agile vs Waterfall

Група энтузіястаў, дастаткова смелых, каб паспрабаваць адаптыўны падыход у ІТ у той час, калі нормай было выкарыстоўваць прэдыктыўны, сабраліся разам і назвалі свой падыход «Agile». Гэта была выдатная ініцыятыва: не абмяжоўваць свой выбар тым, што здавалася абавязковым. У Аgile супольнасці, па-ранейшаму, шмат энтузіястаў і людзей, арыентаваных на вынік, але, на жаль, ёсць людзі, якія ператвараюць Agile ў культ, і якія лічаць усіх навокал ворагамі. Гэта выклікае праблемы, напрыклад:

  • Гэта не дазваляе ім вучыцца ў каго-небудзь за межамі іх групы.
  • Гэта перашкаджае староннім вучыцца ў іх.
  • Гэта робіць прыналежнасць да групы больш важнай, чым рэальная мэта, што, у сваю чаргу, перашкаджае многім яе членам даведацца аб праўдзівам значэннi Agility.

Гэтую праблему можна зняць, калі выкарыстоўваць тэрмін «Agile» у дачыненні да падыходу да распрацоўкі, а не супольнасці; і калі людзі, якія лічаць сябе стваральнікамі, решацелямі праблем і лідэрамі, будуць разглядаць Agile як адзін з інструментаў, а не як сваю ідэнтычнасць.

Для сапраўдных прафесіяналаў не існуе вайны паміж Agile і вадаспадам.

Прыклад: PRINCE2® vs PMBOK® Guide

У супольнасці ёсць шмат прафесіяналаў, якія звязваюць сябе з PRINCE2® або PMBOK® Guide (звычайна з-за свайго геаграфічнага становішча) і не знаёмыя з іншымі падыходамі. Ва ўсіх нас могуць быць перавагі ў дачыненні да пэўных інструментаў, але не варта сябе з імі ідэнтыфікаваць - важней азнаёміцца з усімі, каб пашырыць нашыя гарызонты.

Сапраўдны прафесіянал адкрыты для ўсіх ідэй, шукае іх, пазнае пра іх і выкарыстоўвае, калі патрабуецца, па-за залежнасці ад прыхільнасцяў.

Прыклад: бесперапыннае навучанне

Прыхільнасці задавальняюць чалавека пачуццём прыналежнасці, якое яны спараджаюць, але не прымушаюць, а часам нават замінаюць яму вучыцца з-за страху страціць гэта пачуццё. Калі вы вольны чалавек, эксперт без прыхільнасцяў, вам неабходна запоўніць прабел навучаннем - няспынным навучаннем.

Тое, што мы ведаем сёння, не з’яўляецца ісцінай у апошняй інстанцыі. Гэта толькі наша разуменне праўды ў моманце, якое трэба паляпшаць, рухаючыся наперад. Калі вашыя погляды за некалькі гадоў наогул не памяняліся, што-то пайшло не так. Гэта дакладна і ў выпадку з NUPP: калі вы звернецеся праз некалькі гадоў і ўбачыце ўсё тое ж самае, у вас павінна закрасціся сумненне.

Прыклад: адкрытасць

Запярэчу камусьці, пераканайцеся, што вашы пярэчанні накіраваны на ідэю, а не на чалавека. Гэта дапаможа знізіць напружанасць. Аналагічна, калі хто-небудзь пярэчыць вам, паспрабуйце не прымаць гэта на свой рахунак, сфакусуйцеся на абмеркаванні ідэй. Не трэба слухаць, каб адказаць, трэба слухаць, каб зразумець. Працуйце з іншымі людзьмі, каб развіваць вашыя ідэі.


беражы і аптымізуй энергію і рэсурсы

Рэсурсы абмежаваныя. Рэсурсы, даступныя для праекта, абмежаваныя гэтак жа, як і разумовая энергія, неабходная для прыняцця правільных рашэнняў. Вы павінны берагчы і аптымізаваць гэты рэсурс для сябе і для праекта, і дапамагаць іншым чальцам каманды рабіць тое ж самае.

Прыклад: правіла 80/20

Большую частку магчымых выгод ад кіравання праектамі можна атрымаць, выдаткаваўшы невялікую частку намаганняў. У большасці выпадкаў імкненне да атрымання 100% магчымых выгод занадта дорага і неапраўдана. Улічвайце гэта правіла ва ўсім, што робіце і падахвочвайце да гэтага іншых.

Прыклад: стомленасць ад прыняцця рашэнняў

Мы выкарыстоўваем адзінаю крыніцу разумовай энергіі для прыняцця ўсіх тыпаў рашэнняў, а таксама для праявы сілы волі. Калі выкарыстоўваць яго для прыняцця непатрэбных або няважных рашэнняў, у вас будзе менш энергіі для важных рашэнняў, што прывядзе да дрэнных вынікаў. Гэта адна з прычын, па якой лепш пазбягаць мікрамэнэджмента (прынцып PRINCE2® «упраўленне па выключэнняў»).

Канфлікты, звязаныя з ідэямі, могуць быць карысныя, але канфлікты, звязаныя з людзьмі, звычайна шкодныя для праекта, і адно з наступстваў гэтага заключаецца ў тым, што ён высільвае разумовую энергію членаў каманды. Калі вы заўважылі такі канфлікт, зрабіце ўсё магчымае, каб знайсці прычыну і ліквідаваць яе.

Прыклад: беражы сябе!

Рашэнні, якія вы прымаеце, і сіла волі, якую вы выказвае, расходуюць вашу разумовую энергію. З іншага боку, энергія папаўняецца, калі вы спіце і правільна харчуецеся. Значыць, вы павінны добра клапаціцца пра сябе: пераканайцеся, што ў вас дастаткова сну і адпачынку, і добра сілкуйцеся. Калі ў вас ёсць шкодныя звычкі або праблемы са сном, не варта змагацца з імі ў адзіночку. Ёсць шмат спецыялістаў, гатовых дапамагчы вырашыць такія праблемы. Фізічная актыўнасць таксама можа дапамагчы з папаўненне энергіі, хоць даследаванні на тэму не даюць адназначных высноў.

Падахвочвайце членаў каманды рабіць тое ж, што і вы. Па-першае, пераканайцеся, што яны працуюць ва ўстойлівым тэмпе і без лішніх перапрацовак. Калі ў вас ёсць магчымасць, прапануйце пажыўную здаровую ежу і напоі ў працоўны час.

Прыклад: баланс паміж працай і асабістым жыццём

Шмат хто з нас любяць сваю працу, але гэта яшчэ не ўсё, што нам трэба ў жыцці. Сапраўды гэтак жа, як вы аптымізуеце сваю працу, вы павінны планаваць і рэалізоўваць ідэі ў сваім асабістым жыцці такім чынам, каб яно былы радасным і шчаслівым. Калі вы шчаслівыя ў жыцці, вы больш паспяховыя і на працы. Калі можаце, паспрабуйце заклікаць членаў вашай каманды зрабіць тое ж самае.

Прыклад: матывацыя

Матывацыя - складаная канцэпцыя. Ёсць некалькі цікавых і карысных рэсурсаў па гэтай тэме, у тым ліку і ненавуковыя. Тым не менш, карысна даведацца больш аб матывацыі і імкнуцца пастаянна ўжываць яе у працы, так як гэта павялічвае разумовую энергію каманды і магчымасць дасягнення лепшых вынікаў для праекта.

Матывацыя можа прымаць такія простыя формы як ўсмешка і «дзякуй» у знак прызнання працы. Дадаткова звярніце ўвагу, што некаторыя з распаўсюджаных формаў матывацыі, напрыклад, невялікія грашовыя ўзнагароды, могуць даць адмоўны эфект.

Прыклад: супрацоўніцтва і камандная праца

Супрацоўнічаючы, людзі могуць дамагацца лепшых вынікаў, але што яшчэ больш важна, мы па сваёй прыродзе таварыскія і любім быць часткай групы. Калі вы зможаце ліквідаваць негатыўныя аспекты каманднай працы і стварыць спрыяльную абстаноўку, ваша каманда стане больш шчаслівей.

Вы павінны быць асцярожныя, таму што людзі розныя, і некаторым трэба праводзіць час у цішыні і адзіноце - неабходна выконваць баланс.

Прыклад: культура адной каманды

Розныя зацікаўленыя стораны маюць тэндэнцыю групавацца, што выклікае напружанасць у адносінах з іншымі групамі; напрыклад, людзі, якія сканцэнтраваны на бізнес-аспектах праекта vs людзі, якія ствараюць прадукт. Гэта напружанне спажывае шмат энергіі з абодвух старон, і гэта адна з прычын, па якой мы павінны паспрабаваць стварыць культуру адной каманды, дзе ўсе працуюць разам для дасягнення адной мэты.

Прыклад: мудрасць натоўпу

Калі вялікая колькасць людзей з розным вопытам і поглядамі збіраюцца разам і працуюць у спрыяльнай асяроддзі, ёсць патэнцыял для атрымання вельмі добрых вынікаў, ідэй і рашэнняў, якія могуць быць нават лепш, чым тыя, што прыходзяць ад асобных экспертаў.

Калі ў вас ёсць такая магчымасць, рэгулярна прыцягвайце каманду да вырашэння складаных пытанняў. Акрамя магчымасці атрымання добрых вынікаў, гэта таксама дае ведаць членам каманды, што іх меркаванне цэніцца і што яны атрымліваюць важную ролю ў праекце, што, у сваю чаргу, павышае іх узровень энергіі. Тэхніка на кроку № 26 з з’яўляецца прыкладам выкарыстання мудрасці натоўпу ў праектах.

Прыклад: галоўны фасілітатара праекта

Калі вы менеджэр праекта, вялікая частка вашай працы мае характар фасілітацыі (ці, па меншай меры, павінна мець). З іншага боку, вы можаце бачыць, што члены каманды ў мінулым мелі негатыўны вопыт работы з мэнэджэрамі праектаў, і што гэты вопыт ўплывае на іх адносіны з вамі: замест даверу частка іх энергіі выдаткоўваецца на аналіз вашых паводзін на прадмет патэнцыйных пагроз. У такім выпадку вы можаце змяніць сваю пасаду з кіраўніка праекта на галоўнага фасілітатара праекта. У канечным ітозе, гэта тое, што вы сапраўды робіце ў праекце.


заўсёды будзь проактыўным

Мы схільныя быць рэактыўнымі, а не проактыўнымі. Гэта можа дапамагчы нам захаваць нашу энергію пры вырашэнні другарадных задач, або можа даць нам лепшыя вынікі, калі мы маем справу з чымсьці, у чым мы зусім некампетэнтныя. Гэтыя сітуацыі адрозніваюцца ад нашых праектаў, і тут мы можам дамагчыся лепшых вынікаў, праявіўшы ініцыятыву.

Прыклад: планаванне

Калі вы вырашылі кудысьці паехаць і ўжо спазняецеся, можна выехаць адразу, каб «сэканоміць час», а магчымыя праблемы вырашаць па меры з’яўлення. Проактыўны падыход складаецца ў тым, каб выдаткаваць некаторы час і спачатку пабудаваць самы хуткі маршрут, які ўлічвае пробкі, аварыі і перакрыцці, а затым ехаць; гэта зойме час, але ў выніку вы яго сэканоміце, пазбегнуўшы праблем.

Нягледзячы на тое, што некаторыя людзі думаюць пра Agile праектах, планаванне неабходна заўсёды, і яно залежыць толькі ад тыпу і ўзроўню дэталізацыі. Планаванне перад выкананнем з’яўляецца проактыўны падыходам.

Памятаеце выраз: дайце мне шэсць гадзін, каб ссекчы дрэва, і я правяду першыя чатыры завострывання сякеры.

Калі гэта прэдыктыўны праект, вы можаце выдаткаваць 4 гадзіны на завострыванне сваей сякеры, таму што вы ўпэўненыя, што збіраецеся ссекчы дрэва. У Agile праекце вы не ўпэўненыя, ці збіраецеся вы секчы дрэва, збіраць зламаныя галіны, стрыгчы газон, здабываць вугаль ці нешта яшчэ. Тым не менш, вам усё роўна трэба падрыхтавацца да гэтых работ у цэлым (даведацца, дзе бліжэйшая крама інструментаў) і падрыхтавацца да канкрэтных работ (завастрыць сякера), калі вы выберыце канкрэтнае рашэнне - гэта таксама планаванне.

Прыклад: падрыхтоўка к планаванню

Планаванне таго, як мы збіраемся выканаць праект, з’яўляецца проактыўным падыходам. Такая проактыўнасць можа быць нават пашырана шляхам планавання таго, як мы будзем планаваць выкананне. Гэта план кіравання праектам з Кіраўніцтва PMBOK®, стратэгіі кіравання PRINCE2® і падыходаў DSDM®.

Прыклад: бесперапыннае планаванне

Рэальнасць рэдка адпавядае таму, што мы запланавалі, і гэта нармальна, але мы павінны пастаянна адаптаваць нашы планы, каб яны заставаліся рэалістычнымі і практычны. Мы павінны рабіць гэта адразу, як толькі патрабуецца карэкціроўка, а не калі мы ўжо сутыкнуліся з праблемамі. Гэта проактыўны падыход.

Прыклад: кіраванне рызыкамі

Уся канцэпцыя кіравання рызыкамі заснавана на проактыўнасці: сутыкаючыся з нявызначанасцю, мы не чакаем, што адбудзецца, каб потым адрэагаваць, а загадзя думаем пра магчымасці і наступствах, разглядаем меры рэагавання і, верагодна, нешта робім да таго, як рызыка рэалізуецца.

Памятаеце, што тое, што мы робім у праектах, сур’ёзна, часам гэта закранае чыесьці жыцце.

Прыклад: вызначэнне роляў і абавязкаў

Вы можаце пакінуць членаў праектнай каманды працаваць без дакладных роляў і абавязкаў, і рана ці позна з’явіцца форма роляў і абавязкаў, але гэта занадта дорага і можа не спрацаваць. Проактыўны падыход складаецца ў тым, каб вызначыць ролі і абавязкі на ранняй стадыі і адаптаваць іх па меры неабходнасці. Гэта палягчае працу для ўсіх, і яны могуць засяродзіцца на стварэнні прадукту, замест таго, каб вырашаць, хто чым займаецца.

Колькасць і разнастайнасць роляў залежаць ад тыпу і памеру праекта; іх набор можа быць строга вызначаны, як, напрыклад, у Scrum, умерана, напрыклад, у, або усёабдымна, як у DSDM® і PRINCE2®. Аднак не забывайце, што апісання роляў у гэтых метадах тычацца толькі кіраўніцкіх аспектаў, - вам заўсёды трэба дадаваць апісання роляў і для тэхнічных аспектаў.

Прыклад: даступныя варыянты

Ці варта заўчасна зачыніць праект або працягнуць?

Вельмі рэдка ў нас сапраўды ёсць толькі два варыянты, нават калі пытанне мае на ўвазе гэта. Вам трэба праяўляць проактыўны падыход і абдумаць усе варыянты, перш чым прымаць рашэнне. Можа быць, вы можаце змяніць праект; магчыма, вы можаце прыпыніць яго, пакуль нешта яшчэ не стане ясным; ці, можа быць, вы можаце змяніць падыход да праекту (напрыклад, аўтсорсінг) і г. д.

Прыклад: крытычнае мысленне

Ва ўсіх нас шмат прадузятасцяў, якія, з аднаго боку, дапамагаюць нам выжываць, а з другога - прыводзяць да няякасным рашэнням. Прымаючы важныя рашэнні па праекце, лепш за ўсё ўзяць паўзу і разгледзець ўсе прадузятасці, якія могуць паўплываць на наша рашэнне, перш чым яны выклічуць праблемы.

У якасці спасылкі вы можаце выкарыстоўваць спіс кагнітыўных скажэнняў, прыведзены ў Вікіпедыі:

Ёсць нават спецыяльныя фреймворкі, якія вы можаце выкарыстоўваць для атрымання якасных рашэнняў. Спачатку іх выкарыстанне можа адцягваць і нават раздражняць, але неўзабаве вы прывыкае да іх і атрымліваеце ад іх перавага без асаблівых свядомых высілкаў.

Прыклад: празрыстасць

Нам не падабаецца зрываць тэрміны або сутыкацца з іншымі праблемамі, але гэта не значыць, што іх трэба хаваць. Вы павінны захоўваць празрыстасць і адкрыта паведамляць аб праблемах стэйкхолдэрам, таму што некаторыя з іх могуць вам дапамагчы, і, акрамя таго, рана ці позна яны ў любым выпадку даведаюцца аб праблемах і іх наступствах, а некаторыя з іх могуць запатрабаваць хутчэйшых дзеянняў з іх боку (напрыклад, прыняць негатыўныя наступствы).

Прыклад: мець эфектыўныя зносіны

Бывае, што вы адпраўляеце справаздачу стэйкхолдэрам і не атрымліваеце зваротнай сувязі. Вы можаце падумаць, што ўсё ў парадку толькі таму, што адмоўных водгукаў няма, хоць гэта можа быць і не так. Вы павінны быць проактыўнымі і правяраць, азнаёміліся ці яны са справаздачай і паслужыў ён дасягнення сваёй мэты, і выкарыстоўваць гэтую інфармацыю для ўдасканалення камунікацый; у адваротным выпадку, гэтая прыхаваная праблема можа выклікаць сур’ёзныя праблемы пазней, калі яе будзе занадта цяжка выправіць.

Прыклад: бярыце на сябе адказнасць

Лёгка вінаваціць іншых у дрэнных выніках. Напрыклад, вы хочаце, каб ваша арганізацыя прадставіла вам карт-бланш, і вы зробіце праект ідэальна, але яны гэтага не робяць, і ў выніку праект трымае няўдачу. Гэта не проактыўны падыход.

Проактыўны падыход заключаецца ў тым, каб узяць на сябе адказнасць і рабіць усё магчымае ў рамках існуючых абмежаванняў. Не варта чакаць, што арганізацыя цалкам вам давярае і дасць зялёнае святло ў надзеі на лепшыя вынікі, асабліва калі яны ўжо бачылі няўдалыя праекты. Зрабіце адно невялікае паляпшэнне ў рамках існуючых абмежаванняў і выкарыстоўвайце яго, каб заваяваць давер, трохі больш рэсурсаў і цярпення, а затым выкарыстоўвайце гэта для крыху большага паляпшэння і так да таго часу, пакуль не дасягне сваёй мэты.


памятай, што трываласць ланцугі вызначаецца па самаму слабаму звяну

У праектах ёсць розныя дамены, і ўсе яны патрабуюць увагі; у нас павінна быць цэласная карціна праекта. Недастаткова звярнуць увагу на, здавалася б, самы важны дамен (напрыклад, тэрміны), таму што ўсе дамены ўзаемазвязаны.

Прыклад: гэта ўсё аб дэдлайне!

Дапусцім, вы будуеце што-то для Алімпійскіх гульняў. У праекта вельмі строгі дэдлайн, што робіць кіраванне тэрмінамі вельмі важным. Ці так гэта?

Што калі якасць настолькі нізкая, што праз некаторы час патрабуецца паўторная праца. Гэта паўплывае на час, значыць, трэба надаваць увагу якасці ў тэрмінах. У вас можа быць мудрагелісты сад, названы ў першапачатковым вызначэнні праекта, але вы ведаеце, што калі не хапае часу, вы можаце прапусціць яго і проста замяніць траўнікам, калі вы своечасова разгледзелі гэтую магчымасць і падрыхтаваліся да яе. Такім чынам, кіраванне зместам таксама важна. Цяпер змест, час і якасць у цэнтры нашай увагі.

Вы чулі пра знакаміты выпадак, калі прэзідэнт Кэнэдзі сустрэў прыбіральніка ў NASA і спытаўся ў яго, што ён робіць? Прыбіральнік адказаў: «Я дапамагаю пасадзіць чалавека на Луну». Хіба такія людзі ў праекце не дапамагаюць выканаць яго ў тэрмін?

Працягваючы, вы заўважаеце, што кожны асобны дамен у праекце спрыяе кіраванні тэрмінамі, і вы не можаце ўкласціся ў тэрмін з прымальным узроўнем верагоднасці, калі не зважаеце на ўсе дамены.

Прыклад: выбарачныя запазычанні

Калі людзі сутыкаюцца з рознымі метадамі, часам яны пачынаюць рабіць выбарачныя запазычанні і ствараюць сумесь за ўсё, што здаецца ім цікавым з розных сістэм. Гэта звычайна не працуе, таму што элементы не працуюць ізалявана і павінны быць сумяшчальныя адзін з адным. Любыя дапаўненні або змяненні ў сістэме павінны быць зроблены з комплекснай пункту гледжання.

Таму мы часам бачым супярэчлівыя элементы ў розных падыходах; нешта добра працуе ў адным, а яго супрацьлегласць добра працуе ў іншым. Самі па сабе гэтыя элементы не з’яўляюцца ні правільнымі, ні няправільнымі.

Самы бяспечны падыход - гэта выбраць метадалогію для праекта, адаптаваць яе, а затым асцярожна дадаць да яе новыя элементы, улічваючы цэласнасць ўсёй сістэмы.

Прыклад: антыпрацесный падыход

Адна з лепшых рэчаў, якую зрабілі Agile-метады, - прыцягненне ўвагі да чалавечых аспектах. Agile Manifesto дае вялікую каштоўнасць асобным асобам і узаемадзеянням у параўнанні з працэсамі і прыладамі, хоць гэта можа і не быць справядлівым параўнаннем. Амаль усе падыходы прызнаюць важнасць чалавечага аспекту, але менавіта ў Agile чалавечыя аспекты ўбудаваны ў працэсы, а не з’яўляюцца іх дадаткам. Такім чынам, гаворка ідзе не аб канкурэнцыі паміж чалавечымі аспектамі і працэсамі, а хутчэй пра тое, як чалавечыя аспекты разглядаюцца ў сістэме.

Няма сумненняў у тым, што некаторыя людзі спрабуюць замяніць чалавечыя аспекты больш складанымі працэсамі, але гэта толькі злоўжыванне. Існуе і зваротная праблема: людзі спрабуюць замяніць працэсы чалавечымі аспектамі, што таксама не вельмі добра працуе.

Прыклад: гэта ўсе дамены, якія вам патрэбныя

Калі вы думаеце аб даменах, будзьце асцярожныя, каб не прапусціць ні адзін з іх. Дарэчы, што гэта за дамены? Калі вы праверыце асноўныя рэсурсы, вы атрымаеце розныя адказы; і ўсё ж, ні адзін з іх не з’яўляецца поўнай праўдай.

Тэмы PRINCE2® - гэта дамены, але гэта толькі тыя дамены, якія гуляюць ключавую ролю ў метадалогіі. Іншыя дамены толькі маюцца на ўвазе.

Кіраўніцтва PMBOK® не з’яўляецца метадалогіяй і можа сфармуляваць адказ значна лепш з дапамогай дзесяці абласцей ведаў. Аднак гэта інтэрпрэтацыі ўсіх даменаў, заснаваныя на пункце гледжання кіраўніцтва PMBOK® на праект, а не на нейтральнай (нейтральная кропка гледжання існуе не заўсёды). Напрыклад, чалавечыя аспекты не атрымліваюць вялікай увагі ў Кіраўніцтве PMBOK®.

Добрым крыніцай інфармацыі аб даменах з’яўляецца ICB. Аднак тут гаворка ідзе не аб даменах, а аб кампетэнцыі, якія патрабуюцца ў праекце. У іх няма адназначных супастаўленняў з даменамі, але гэта вельмі дапамагае ў іх ідэнтыфікацыі.

У NUPP няма спісу даменаў, у першую чаргу таму, што гэта хутчэй метасістема, чым сістэма, а таксама таму, што катэгарызацыі даменаў залежыць ад тыпу праекта і яго асяроддзя; напрыклад, руцінны будаўнічы праект можа мець патрэбу ў іншым падыходзе, чым творчы даследчы праект.


не рабі нічога без выразнай мэты

Вы не павінны нічога рабіць, калі гэта не мае выразнай мэты. Уявіце сабе два паралельных свету, у якіх усе аднолькава, за выключэннем таго, што вы плануеце рабіць: наколькі рознымі будуць гэтыя міры? Хіба розніца каштуе намаганняў, каб зрабіць гэта?

Калі ў вас няма яснай мэты і вы робіце нешта толькі таму, што гэта робяць усе астатнія, ці ўсё кажуць, што гэта важна, то:

  • гэта можа не прынесці вам рэальнай карысці, і, такім чынам, вы можаце нічога не атрымаць ад гэтага.
  • ці ж у вашым выпадку ён усё яшчэ можа мець патэнцыйныя выгады, але паколькі ў вас няма гэтай мэты, ваш спосаб зрабіць гэта можа не дапамагчы рэалізаваць перавагі.

Прыклад: партфоліо і праграмы

Калі вы ўдзельнічаеце ў адборы і запуску праектаў, пераканайцеся, што вы сканцэнтраваны на развязальных праблемах і ствараемых перавагах, а не на тэхнічных рашэннях. Класічным прыкладам з’яўляецца вытворца ліфтаў, які атрымліваючы скаргі на хуткасць сваіх ліфтаў, запусціў некалькі праектаў па павелічэнні хуткасці без асаблівага поспеху. Гэта працягвалася да таго часу, пакуль яны не вырашылі засяродзіцца на праблеме (нуда або дыскамфорт людзей) замест «натуральнага» рашэння (больш хуткія ліфты). У выніку яны дадалі люстэрка ў ліфты, і гэта вырашыла праблему проста і танна.

Памятаеце, што кіраванне праектамі - гэта ў асноўным правільныя дзеянні, а кіраванне партфелямі - правільныя рэчы. Усё роўна, наколькі добра вы кіруеце сваімі праектамі; гэта не спрацуе, калі вы робіце няправільныя праекты. Усё гэта пра наяўнасць мэты.

Прыклад: праект у цэлым

Гнуткасць прадукту вар’іруецца паміж праектамі. У некаторых праектах па развіццю ІТ прадукт з’яўляецца цалкам гнуткім, і яго канчатковая форма залежыць ад зваротнай сувязі, якая будзе генеравацца па инкрементам прадукту ў ходзе праекта, што патрабуе прымянення адаптыўнага (гнуткага) падыходу. На практыцы гэта камбінацыя узроўняў партфеля, праграмы і праекта і патрабуе максімальнай увагі да канчатковай мэты. Рэкамендуецца задакументаваць мэта і зрабіць яе даступнай; гэта адна з мэтаў «бачання прадукта», якое выкарыстоўваецца ў некаторых праектах Scrum. Увага да кошту бізнесу ў Agile праектах - гэта іх спосаб забяспечыць адпаведнасць мэты.

У іншых тыпах праектаў, дзе прадукт з’яўляецца адносна фіксаваным і існуюць іншыя механізмы, якія гарантуюць, што канчатковы прадукт будзе задавальняць мэты, члены праектнай каманды могуць перанесці большую частку сваёй увагі з мэты на прадукт (такім чынам, прынцып «засяродзіць увагу на прадуктах» (PRINCE2®)), але ўсё ж патрабуецца па меншай меры мінімальнае увагу мэты, каб гарантаваць, што тое, што будуецца, будзе адпавядаць мэты, што можна зрабіць шляхам параўнання прагназуемых выгад з чаканымі (прынцып «пастаянная ацэнка мэтазгоднасці» і тэма «эканамічнае абгрунтаванне» у PRINCE2®).

Калі праект запускаецца для внешняга кліента, у кліента будзе свая мэта праекта, а ў вас свая. Каб атрымаць поспех, вам трэба разумець абедзве.

Прыклад: маніторынг праекта

Неабходна засяродзіцца на канчатковай мэте, але яна можа быць занадта абстрактнай для многіх паўсядзённых задач. Вось чаму для эфектыўнай працы неабходная іерархія мэтаў. Спачатку абгрунтаванне і выгады праекта вызначаюцца на аснове канчатковай мэты, а затым у вас з’яўляюцца відавочныя і няяўныя мэты для зменных праекта (напрыклад, тэрміны, кошт і якасць), дасягаючы якія вы, у сваю чаргу, задавальняеце канчатковую мэту. Гэта мэты больш нізкага ўзроўню, якія карысныя для многіх нашых паўсядзённых задач.

Калі справа даходзіць да маніторынгу, нізкаўзроўневы маніторынг праекта будзе ажыццяўляцца з выкарыстаннем самага нізкага ўзроўню зменных, паколькі адсачыць канчатковую мэту не заўсёды магчыма. У гэтым выпадку трымаеце ў розуме: якая мэта маніторынгу?

Нармальны і прымальны адказ - паглядзець, знаходзімся мы на правільным шляху, і калі няма, здзейсніць пэўныя дзеянні, каб вярнуцца ў ранейшае рэчышча, або скарэктаваць мэты і паглядзець, ці зможам мы па-ранейшаму дасягнуць канчатковую мэту. Таму нашы вымярэнні павінны быць у стане дапамагчы справіцца з гэтай нізкаўзроўневай задачай, а таксама сфармаваць прагноз па завяршэнні для зменных праекта; напрыклад, калі мы зможам завяршыць праект? Колькі грошай нам спатрэбіцца, каб скончыць праект?

Усе астатнія вымярэння, такія як планавыя і фактычныя значэнні на сённяшні дзень, з’яўляюцца толькі прамежкавымі значэннямі, якія вам патрэбныя для разліку прагнозаў, а не канчатковымі значэннямі, якімі вы карыстаецеся для кіраўніцкіх мэтаў.

Прыклад: дакументы

Незалежна ад таго, які падыход да распрацоўкі вы выкарыстоўваеце ў праекце, планаванне заўсёды неабходна. Важным пытаннем з’яўляецца ўзровень дэталізацыі кожнага тыпу плана. Калі ў плане недастаткова падрабязнасьцяў, план не зможа ўнесці дастатковы ўклад, і выкананне праекта будзе заснавана на спантанных рашэннях, а не на комплексных, цэласных рашэннях. З іншага боку, многія людзі імкнуцца быць асцярожнымі і дадаюць занадта шмат дэталяў да свайго плану, што робіць яго занадта складаным для падрыхтоўкі і суправаджэння і занадта жорсткім для нявызначанасці праекта. У выніку план становіцца нерэальным і бессэнсоўным.

Лепшы спосаб вызначыць узровень дэталізацыі - гэта мець мэта для кожнага элемента ў плане. Напрыклад, калі вы разглядаеце магчымасць дадання рэсурсаў у план, у вас павінна быць для гэтага мэта: як вы збіраецеся яго выкарыстоўваць? Як гэта дапаможа праекту? Колькі высілкаў гэта зойме? і ці варта гэта таго?

Часам трэба вырашыць, ці вы хочаце мець пэўны элемент у сваіх планах, а часам - то, як вы хочаце спланаваць або падрыхтаваць нешта. Няхай гэта будзе эканамічнае абгрунтаванне, статут праекта або справаздачу: вы ўсё роўна павінны спытаць сябе, чаму вы рыхтуеце гэты дакумент і як ён можа дапамагчы праекту.

Пошук «шаблону» - гэта супрацьлегласць таму, каб рабіць нешта на аснове мэты.

Прыклад: статус-справаздачы

Па праектах часта фарміруюць сапраўды доўгія статус-справаздачы. Грунтуючыся на гэтым NUP, мы павінны спытаць сябе, якая мэта справаздачы і як мы можам дасягнуць гэтай мэты незалежна ад таго, як паступае большасць іншых людзей.

Гэта можа прывесці да таго, што мы пачнем фарміраваць вельмі простыя одностраничные справаздачы, якія зацікаўленыя бакі сапраўды прачытаюць і зразумеюць, у супрацьлегласць доўгім. Гэта азначае ўвагу да мэты.

Аднак, калі вы рыхтуеце аднастаронкія справаздачы, некаторыя людзі могуць пярэчыць і думаць, што ў вас няма «належнай» сістэмы маніторынгу. На практыцы гэта стварае для вас другую мэту (акрамя першай мэты - дапамагчы зацікаўленым бакам зразумець статус праекта), і каб задаволіць яе, вы можаце проста стварыць другі тып справаздачы, які будзе вельмі доўгім. Пры гэтым вы не будзеце змешваць яго з першым справаздачай, таму што гэтыя дзве мэты не супадаюць.

Прыклад: бізнес-кейс і статут праекта

Падрыхтоўка дакументаў, такіх як бізнес-кейс і статут праекта, звычайна з’яўляецца сумнай, бясплоднай, бюракратычнай неабходнасцю, у той час як усе гэтыя дакументы маюць абгрунтаванне і дастасавальныя да большасці праектаў. Калі вы паспрабуеце знайсці «шаблон» і запоўніць яго, праца будзе проста зроблена марна; тым часам як вы можаце замест гэтага праверыць рэальнае прызначэнне гэтых дакументаў, паглядзець, ці могуць яны дапамагчы ў вашым праекце і якім чынам яны могуць дапамагчы, а затым падрыхтаваць дакумент так, як вам падабаецца, проста для дасягнення гэтых мэтаў: гэта будзе правільны дакумент.

Пакуль вы думаеце пра тое, як падрыхтаваць дакументы для дасягнення іх мэтаў, вы забыцца разгледзець усе варыянты. Каб пазбегнуць гэтага, вы можаце праверыць, што прапануюць PRINCE2®, PMBOK® Guide, і DSDM®, а затым ацаніць гэтыя варыянты ў залежнасці ад мэтаў.

Прыклад: пост-праект

Хоць праект мае пэўную мэту, і мы можам ўлічваць гэтую мэту на працягу ўсяго праекта, рэалізацыя мэты ў асноўным ацэньваецца на аснове прагнозаў, зробленых у ходзе праекта. Аднак, не варта забываць пра гэта, калі праект завершаны. Важна праверыць рэалізацыю мэтаў пасля завяршэння праекта, таму што:

  • мы можам убачыць, як дасягаюцца канчатковыя мэты і атрымаць з гэтага ўрокі для будучых праектаў, і
  • часам мэты дасягаюцца толькі тады, калі мы робім некаторыя дадатковыя дзеянні пасля завяршэння праекта, і разуменне неабходнасці гэтых дадатковых задач патрабуе кантролю.

Постпраектны маніторынг з’яўляецца неабходным крокам для дасягнення мэты. У асноўным гэта зона адказнасці кіравання праграмамі і партфелямі, і паколькі большасць кампаній не маюць такіх узроўняў кіравання, гэтым крокам звычайна трэбуюць. Вось чаму такія метады, як і DSDM®, дадаюць гэты крок у метадалогіі кіравання праектамі.

Прыклад: прастата

Свет складзены і хаатычны, але нашы мадэлі ўяўляюць сабой абстрактныя набліжэння, якія адлюстроўваюць часткі свету, і, такім чынам, яны могуць быць простымі. З іншага боку, простыя сістэмы звычайна працуюць лепш, таму што мы можам засяродзіцца на асноўнай ідэі. Шмат хто з нас спрабуюць дамагчыся лепшых вынікаў, дадаючы складанасць да нашых сістэмах, спадзеючыся, што яна будзе адпавядаць складанасці усяго свету, хоць на практыцы гэта абцяжарвае працу з сістэмай і, як правіла, перашкаджае нам дасягнуць мэты.

Прыклад: адаптацыя

Праграмнае забеспячэнне для струменевай музыкі вельмі адрозніваецца ад праграмнага абяспячэння, якое будзе выкарыстоўвацца для абсталявання ў бальніцы або самалёце, дзе ад яго можа залежаць жыццё людзей, ці ад праграмнага обяспячэння, якое будзе выкарыстоўвацца на спадарожніку, дзе яно, як мяркуецца, будзе працаваць шмат гадоў без збояў, усё гэта адрозніваецца ад будаўніцтва летняй дачы, пажарнай станцыі або завода. Факусуючыся на мэтах, вы лепш зразумееце, як адаптаваць сістэмы і артэфакты для розных праектаў.


выкарыстоўвай прайграваныя элементы

Спантанны падыход да праекту патрабуе занадта шмат энергіі і рэсурсаў, і вы заўсёды маеце рызыку прапусціць некаторыя з неабходных элементаў. Лепшы спосаб спрасціць працу - выкарыстоўваць прайграваным элементы, пажадана ў паўтаральных цыклах.

Прыклад: чэк-лісты якасці

Чэк-ліст - гэта просты прыклад патэнцыйна паўтараюцца элементы, які многія людзі выкарыстоўваюць і ў асабістай і прафесійнай жыцці. Вазьміце, напрыклад, крытэрыі якасці прадукту:

  • па-першае, вы можаце стварыць спіс усіх крытэрыяў, што ўжо з’яўляецца формай планавання.
  • NUP6 рэкамендуе паспрабаваць абагульніць іх: ці ёсць іншыя падобныя прадукты ў праекце? У такім выпадку зрабіце агульны чэк-ліст якасці для гэтай катэгорыі прадуктаў. Калі магчымыя варыяцыі, захавайце агульны спіс і дадайце некалькі дадатковых элементаў для асобных прадуктаў. Зараз у вас ёсць прайграваным чэк-лісты.
  • пасля таго, як вы падрыхтуеце агульныя чэк-лісты для розных тыпаў прадуктаў, вы можаце знайсці паўтараюцца пункты і зрабіць для іх віртуальную бацькоўскую катэгорыю. У гэтым выпадку замест паўтарэння элементаў для ўсіх гэтых агульных кантрольных спісаў вы можаце атрымаць іх і змясціць у бацькоўскі чэк-ліст. У канцы ў вас, верагодна, будзе адзіны агульны кантрольны спіс для ўсяго праекта. «Definition of Done» у Scrum з’яўляецца прыкладам выкарыстання чэк-лістоў на ўзроўні праекта для праверкі якасці (магчыма, сярод іншага). Такім чынам, кожны вынік будзе належаць іерархіі катэгорый і павінен задавальняць элементам, якія з’яўляюцца ў кантрольных спісах ўсіх катэгорый у іх ланцужку.

Такім чынам, элемент у бацькоўскай чэк-лісце стане паўтараным для ўсіх вынікаў, якія знаходзяцца пад ім, што эканоміць час і энергію пры планаванні і выкананні.

Што яшчэ больш важна, як толькі вы зробіце гэта для аднаго праекта, вы можаце адаптаваць і выкарыстоўваць яго для ўсіх аналагічных праектаў у будучыні, што з’яўляецца паўтараемай формай планавання для некалькіх праектаў.

Прыклад: працэсы і працоўныя працэсы

Некаторыя прадукты ці звязаныя з імі мэты патрабуюць стандартызацыі і узнаўляльнасці пэўных крокаў. Напрыклад, калі прадукты павінны быць распрацаваны індывідуальна і зацверджаны, вы можаце распрацаваць просты працоўны працэс, у якім будуць зразумелыя ўсе этапы, задзейнічаныя асобы і прыблізная працягласць, што дазволіць пазбегнуць многіх цяжкасцяў. Аднак варта выконваць асцярожнасць, каб не ўскладняць працэсы, паколькі гэта будзе мець негатыўныя наступствы. Усе ўдзельнікі праекту павінны разглядаць бізнес-працэсы як падтрымку і спрашчэнне, а не як бюракратыю, якая замінае працы.

Гнуткія праекты маюць прайграваным элементы ў сваім ітэратыўным падыходзе да распрацоўкі, дзе пэўны тып дзеянняў паўтараецца для кожнай фічы; напрыклад, звычайная штодзённая руціна ў XP (экстрэмальным праграмаванні): аб’яднанне ў пару, выбар элемента, праектаванне на дошцы, стварэнне сцэнарыяў тэсту і кода, інтэграцыя кода і г. д.

Акрамя прайграваных працэсаў, якія можна выкарыстоўваць для тэхнічных дзеянняў, у вас могуць быць паўтараныя элементы для дзеянняў па кіраванні праектамі. Працэсы ў Кіраўніцтве PMBOK®, PRINCE2® і DSDM®, крокі ў і падзеі ў Scrum з’яўляюцца прыкладамі гэтай канцэпцыі.

Прыклад: цыклы

Карысна выкарыстоўваць прайграваным элементы для кіравання праектам. Гэта можа быць зрабіць яшчэ прасцей, калі размяшчалі іх у паўтараюцца цыклы. Гэтыя цыклы значна спрашчаюць паўсядзённае працу людзей, уцягнутых у кіраванне і кіраўніцтва праектам. Цыклы груп працэсаў у Кіраўніцтве PMBOK® пры выкарыстанні ў праекце з некалькімі фазамі, этапамі ў PRINCE2®, штодзённымі, штотыднёвымі і штомесячнымі цыкламі ў, ітэрацыі і часовымі рамкамі ў DSDM® і спрынце ў Scrum з’яўляюцца прыкладамі гэтай канцэпцыі.

Больш за кароткія цыклы лягчэй зразумець і выкарыстоўваць, чым больш доўгія; напрыклад, спрынты ў Scrum ў параўнанні з фазамі з кіраўніцтва PMBOK®. Аднак занадта кароткія цыклы падыходзяць не для ўсіх тыпаў праектаў, рашэннем можа быць выкарыстанне спалучэння некалькіх тыпаў цыклаў, напрыклад кароткія таймбоксы ў спалучэнні з больш доўгімі ітэрацыі ў DSDM®, або выкарыстанне штодзённых, штотыднёвых і штомесячных цыклаў ў

Прыклад: метады

Выкарыстанне метадалогіі або фреймворка для запуску праекта - яшчэ адзін прыклад выкарыстання прайграваных элементаў. Гэта можа быць ўжо існуючая сістэма, такая як PRINCE2®,, DSDM® або Scrum, або сістэма, якую вы наладзілі або стварылі самастойна. Аднак, як правіла, лепш пачаць з аднаго з існуючых метадаў і адаптаваць яго да сваіх патрэбам, чым ствараць свой з нуля.

Любы паўтораны элемент з’яўляецца абстрактным і мае патрэбу ў наладзе, каб адаптаваць яго да рэальнага свету. Тым не менш, існуюць розныя ступені і абстракцыі і патрэбнасці ў адаптацыі: невялікія, адносна канкрэтныя чэк-лісты якасці знаходзяцца на адным канцы спектру з найменшай узроўнем абстракцыі і патрэбай у адаптацыі, у той час як метадалогіі знаходзяцца на іншым канцы, з самай высокай патрэбай у адаптацыі. Вы павінны заўсёды ўлічваць неабходнасць адаптацыі, у адваротным выпадку прайграваны элемент не будзе адпавядаць вашым патрэбам.


NUPP - це сукупність майже універсальних принципів проектів: тих, яких ми б мали дотримувались у всіх проектах, незалежно від методологій та підходів, якими ми користуємось, щоб досягти максимального успіху.

Кожен із доступних ресурсів та методів для виконання проектів спирається на деякі з цих NUP (майже універсальних принципів). Однак слід пам’ятати про наступні моменти:

  • Зазвичай використовуються не всі принципи, але практикам було б корисно розглянути всі NUP замість частини.
  • Основні принципи, як правило, мають недостатнє роз’яснення в ресурсах та методах, і більшість практикуючих настільки займаються практичними деталями, що забувають про принципи та роблять речі, які не сумісні з ними.

NUPP сумісний з усіма основними методами, системами, ресурсами та структурами, такими як PRINCE2®, PMBOK® Guide,, PM², DSDM®, XP та Scrum. Це, можливо, не сумісне з певними інтерпритаціями цих систем, і саме там NUPP намагається закликати практиків переглянути свої інтерпритації.

NUPP - це сукупність таких NUP:


Віддавайте перевагу результатам та істині, ніж приналежності

У всіх нас є природна схильність до належності до груп, тенденція, яка часто виходить за рамки її основної форми, створює міцну приналежність і викликає проблеми. Ми втрачаємо набагато більше, ніж отримуємо через приналежності. Ми можемо стати більш професійними та ефективними експертами, якщо не обмежимо свою особистість та уподобання певними групами.

Приклад: Agile vs Водоспад

Група сильно захоплених людей, які були достатньо сміливими, щоб спробувати адаптаційні підходи до розвитку ІТ в той час, коли нормою було використання прогнозних підходів, зібралися разом, і назвали свій підхід “Agile” (спритний). Це була чудова ініціатива не обмежувати вибір тим, що здавалося необхідним. У спільноті Agile є ще багато захоплених та орієнтованих на результат людей, але, на жаль, в цій спільноті також є деякі люди, які перетворюють Agile на культ і вважають усіх сторонніх людей ворогами. Це спричиняє проблеми різними способами, включаючи наступне:

  • Це не дозволяє їм вчитися у когось поза їхньою групою
  • Це перешкоджає стороннім людям навчатися у них
  • Це робить приналежність до групи важливішою за реальну мету, що, у свою чергу, заважає багатьом її членам пізнати справжнє значення Agility.

Цю проблему можна значно зменшити, якщо не повністю усунути, використовуючи “Agile” лише як термін, що стосується підходу до розвитку, а не як спільноти з членами; і маючи людей, які вважають себе творцями, лідерами та вирішують проблеми, які сприймають Agile просто як один з інструментів, а не як свою ідентичність.

Немає війни між Agile та Водоспадом для справжніх професіоналів.

Приклад: PRINCE2® vs PMBOK® Guide

У професійній спільноті є багато фахівців, які пов’язують себе з PRINCE2® або PMBOK® Guide (як правило, через своє географічне розташування) і не знайомі з іншими. Усі ми можемо мати переваги щодо певних джерел, але не слід ідентифікувати себе з ними, і що найважливіше, ми повинні ознайомитись із усіма ними, щоб розширити нашу перспективу та вибір.

Справжній професіонал відкритий до всіх ідей, шукає їх, дізнається про них і використовує їх, коли потрібно, без прояву приналежності.

Приклад: Безперервне навчання

Приналежності задовольняють людину завдяки почуттю належності, яке вони породжують, але яка не підштовхує їх навчатись, а іноді навіть відштовхує їх від навчання, оскільки вони бояться втратити свою приналежність. Коли ви вільна людина, експерт без приналежностей, вам потрібно заповнити прогалину навчанням: безперервним навчанням.

У що ми віримо сьогодні, це не є істиною. Це просто наше найкраще розуміння на даний момент, яке треба вдосконалювати в процесі роботи. Щось неправильно, якщо ваші погляди сущільно збігаютться з тими, що були кілька років тому. Це стосується навіть NUPP: якщо ви повертаєтесь через декілька років і побачите абсолютно те саме, то у вас має закрастися сумнів.

Приклад: Відкритість

Заперечуючи проти когось, переконайтеся, що ви націлили своє заперечення саме на ідею, а не на людину. Це допомагає запобігти великій напрузі. У подібному руслі, коли хтось заперечує вам чи проти вас, постарайтеся не тлумачити це як війну проти вас, а скоріше обговорення ваших ідей, і будьте відкриті до неї. Не слухайте, щоб відповісти; слухайте, щоб зрозуміти; співпрацюйте з іншою людиною, щоб вдосконалити ідею.

Деякі люди можуть навмисно націлитися на вас замість ідеї; у такому випадку вам слід допомогти їм зосередитись на ідеї, а не на вас, перш ніж продовжувати, і спробувати зберегти зосередженість на йдеї протягом усієї розмови.


Зберігайте та оптимізуйте енергію та ресурси

Ресурси обмежені. Ресурси, доступні для проекту, обмежені, як і ментальна енергія, яку ви маєте витратити, щоб прийняти правильні рішення. Ви повинні зберегти та оптимізувати цей ресурс для себе та для проекту, та допомогти іншим членам команди зробити те саме.

Приклад: Правило 80/20

Значну частину можливих переваг управління проектами можна отримати, витративши невелику частину зусиль. У більшості випадків орієнтація на 100% можливих вигод є дуже дорогою і невиправданою. Вам потрібно враховувати це правило у всьому, що ви робите, і заохочувати інших робити те саме.

Приклад: Втома від прийняття рішення

Ми використовуємо єдине джерело психічної енергії для прийняття всіх типів рішень, а також для вираження сили волі. Якщо ви використовуєте багато цього джерела для прийняття непотрібних чи неважливих рішень, у вас буде менше енергії для важливих рішень, що може призвести до поганих результатів. Це одна з причин, коли вам слід уникати мікроменеджменту (принцип “керувати за винятком” PRINCE2®).

Конфлікти, пов’язані з ідеями, можуть бути корисними, але ті, які стосуються людей, як правило, шкідливі для проекту, і одним із наслідків є те, що такий конфлікт виснажує психічну енергію членів команди. Якщо ви помітили такий конфлікт, вам слід зробити все можливе, щоб знайти першопричину та вирішити її.

Приклад: Подбайте про себе!

Рішення, які ви приймаєте, і сила волі, яку ви висловлюєте, використовують ваше джерело психічної енергії. З іншого боку, це джерело наповнюється енергією, коли ви спите і харчуєтесь правильно. Отже, слід добре дбати про себе: переконайтеся, що ви виспалися і відпочили, і харчуйтеся добре. Якщо у вас є шкідливі звички або проблеми зі сном, вам не доведеться з цим боротися поодинці; є багато фахівців, які можуть допомогти вам виправити подібні проблеми. Фізичні навантаження також можуть допомогти з цим джерелом енергії, хоча дослідження ще не є остаточними для цього питання.

Спробуйте заохотити членів команди робити те саме, що і ви. По-перше, переконайтесь, що вони працюють стійкими темпами та без зайвих понаднормових робіт. Потім, якщо у вас є вибір, спробуйте запропонувати в робочий час енергійну, здорову їжу, закуски та напої.

Приклад: Баланс роботи та життя

Багато хто з нас любить те, що ми робимо, але це все ще не все, що нам потрібно мати в житті. Таким же чином, як ви оптимізуєте свою роботу, ви повинні планувати та впроваджувати ідеї в особистому житті таким чином, щоб зробити його радісним та щасливим. Коли ви більш щасливі, ви моєте бути більш успішними і у роботі. Якщо можете, спробуйте заохотити членів вашої команди зробити те саме.

Приклад: Мотивація

Мотивація - це складне поняття. Є цікаві та корисні джерела з цих тем, а також багато інших ненаукових. Проте, корисно дізнатися більше про мотивацію і намагатися постійно застосовувати в роботі, так як це збільшує розумову енергію команди і можливість досягнення кращих результатів для проекту.

Мотивація може приймати такі прості форми як посмішка або “спасибі” в знак визнання роботи. Проте будьте обережні, так як деякі з поширених форм мотивації, наприклад, невеликі грошові винагороди, можуть мати негативний ефект.

Приклад: Співпраця та командна робота

Люди, які співпрацюють, іноді можуть мати можливість створювати кращі результати, але що ще важливіше, люди є соціальними і люблять бути частиною групи. Якщо ви зможете усунути негативні аспекти роботи в команді та створити приємне середовище, члени команди проекту будуть щасливіші.

Але ви повинні бути обережнішими, тому що люди різні, а комусь потрібен більш спокійний, зосереджений та самотній час, ніж іншим; зазвичай необхідно дотримуватися балансу.

Приклад: Культура єдиної команди

Існує тенденція, щоб різні зацікавлені сторони створюють підгрупи, що стає джерелом напруги з іншими групами; наприклад, люди, орієнтовані на бізнес-аспекти проекту порівняно з людьми, які будують продукт. Ця напруга споживає багато енергії з обох сторін, що є однією з причин, щоб ми намагалися побудувати культуру єдиної команді, де всі працюють разом для досягнення однієї і тієї ж мети.

Приклад: Мудрість натовпу

Коли велика кількість різноманітних людей збирається і працює в сприятливому середовищі, є потенціал отримати дуже хороші результати, ідеї та рішення, які можуть бути навіть кращими, ніж ті, що надходять від окремих експертів.

Якщо у вас є такий варіант, ви можете використовувати його регулярно, щоб звертатись до членів команди про допомогу вам у вирішенні складних проблем в проекті. Окрім можливості отримати хороші результати, це також дозволяє членам команди знати, що їх думка цінується і що вони відіграють важливу роль у проекті, що, в свою чергу, підвищує рівень їх енергії. Діяльність №26 - приклад використання мудрості натовпу у проектах.

Приклад: Головний фасилітатор проекту

Якщо ви керівник проекту, більшість речей, які ви робите, мають характер фасилітації (або, принаймні, повинні мати). З іншого боку, ви можете побачити, що в минулому члени команди мали поганий досвід роботи з менеджерами проектів, і що цей досвід впливає на їхні стосунки з вами: частина їх енергії витрачається на аналіз вашої поведінки на предмет можливих загроз, а не на довіру вам. У такому випадку ви можете змінити назву посади з керівника проекту на головного фасилітатора проекту. Зрештою, саме цим ви й займаєтесь у проекті.


Завжди будьте проактивним

В нас є природна тенденція бути реактивними. Це може допомогти нам зберегти свою енергетичну справу, що стосується неважливих питань, або може дати кращі результати, коли ми маємо справу з тим, у чому ми абсолютно некомпетентні. Ці ситуації відрізняються від наших проектів, і тут ми можемо отримати кращі результати, проявляючи активність.

Приклад: Планування

Якщо ви хочете їхати на нове місце, а ви запізнюєтесь, можете негайно почати рух, щоб “заощадити час”, і вирішити можливі проблеми, коли вони виникнуть. Проактивний підхід полягає в тому, щоб витратити деякий час на старті і встановити вашу навігаційну систему, щоб надати вам найшвидший маршрут на основі трафіку та можливих аварій і перекриттів, а потім їхати; це витрачає час перед виконанням задля уникнення проблем і таким чином заощаджує час.

На відміну від того, що деякі люди думають про Agile проекти, планування завжди є необхідним, і мова лише про тип та рівень деталей у планах. Планування перед виконанням - це активний підхід.

Запам’ятайте цитату: дайте мені шість годин, щоб зрубати дерево, і я проведу перші чотири для заточування сокири.

Якщо проект прогнозований, ви можете витратити 4 години на заточування сокири, оскільки ви впевнені, що збираєтеся рубати дерево. У проекті Agile ви не впевнені, чи збираєтесь рубати дерево, збирати зламані гілки, збирати дернину, видобувати вугілля чи щось інше. Тим не менш, вам все-таки потрібно провести загальну підготовку до всіх цих робіт (знайти, де знаходиться найближчий магазин обладнання), і мати певну підготовку (заточування), коли ви збираєтеся зосередитися на певному рішенні; це і є планування.

Приклад: Планування планування

Планування того, як ми збираємось виконати проект, є проактивним підходом. Цю активність можна навіть розширити, запланувавши спосіб планування виконання; це концепція плану управління Керівництва PMBOK®, стратегій управління PRINCE2® та підходів у DSDM®.

Приклад: Безперервне планування

Реальність рідко відповідає тому, що ми планували, і це нормально, але ми повинні постійно адаптувати наші плани, щоб переконатися, що вони залишаються реалістичними та практичними. Ми повинні робити це, як тільки потрібна адаптація, а не тоді, коли ми стикаємося з проблемами. Це проактивний підхід.

Приклад: Управління ризиками

Вся концепція управління ризиками базується на проактивності: коли ми стикаємося з невизначеними подіями, замість того, щоб чекати, що з’явиться, а потім реагувати, ми думаємо про можливості та наслідки, розглядаємо відповіді та, ймовірно, робимо щось щодо цього, перш ніж це станеться.

Зауважте, що те, що ми робимо в проектах, є серйозним; іноді це стосується життя людей.

Приклад: Визначте ролі та обов’язки

Ви можете залишити членів проектної групи працювати без чітких ролей і обов’язків, і рано чи пізно з’явиться форма ролей і обов’язків, але це занадто дорого і може зрештою не працювати добре. Проактивний підхід полягає в тому, щоб визначити ролі та обов’язки рано та адаптувати за потребою. Це полегшує роботу всім, і допоможе зосередитись на створенні чогось, а не вирішувати, хто чим займається.

Кількість та різноманітність ролей залежать від типу та розміру проекту; це може бути просте визначення, наприклад, одне у Scrum, щось помірне, як, наприклад, у, або щось всеосяжне на зразок DSDM® та PRINCE2®. Однак не забувайте, що описи ролей у цих методах стосуються лише управлінської діяльності та що вам завжди потрібно додавати описи ролей і для технічних аспектів.

Приклад: Доступні варіанти

Чи слід достроково закривати проект чи продовжувати його?

Рідко є лише два варіанти, навіть якщо питання передбачає це. Потрібно мати активний підхід і врахувати всі свої варіанти, перш ніж приймати рішення. Можливо, ви можете переробити зміст проекту; можливо, ви можете зробити паузу, поки щось інше не стане зрозумілим; або, можливо, ви можете змінити проектний підхід (наприклад, аутсорсинг) тощо.

Приклад: Критичне мислення

У всіх нас є багато упереджень, які допомагають нам, з одного боку, вижити і змушують нас приймати погані рішення, з іншого. Що стосується прийняття важливих рішень щодо проекту, то краще заздалегідь зробити паузу та розглянути всі упередження, які можуть вплинути на наше рішення, перш ніж вони спричинять проблеми.

В якості довідки можна використовувати список когнітивних упереджень, наведений у Вікіпедії:

Навіть існують структури (фреймворки) прийняття рішень, які можна використовувати для прийняття кращих рішень. Спочатку їх використання може відволікати і навіть дратувати, але незабаром ви звикаєте до них і отримуєте перевагу від них без особливих усвідомлених зусиль.

Приклад: Прозорість

Нам не подобаються затримки з проектом або якісь інші проблеми, але це не означає, що ми повинні їх приховувати. Ви повинні бути прозорими та повідомляти зацікавленим сторонам про проблеми, оскільки деякі з них можуть допомогти вам, і, крім того, вони рано чи пізно дізнаються про проблеми та їх наслідки, а деякі з них можуть вимагати завчасних дій зі свого боку (наприклад, прийняти негативний наслідок).

Приклад: Спілкуйтеся ефективно

Може бути багато випадків, коли ви надсилаєте звіти зацікавленим особам, і вони не дають вам жодних відгуків. Ви можете вважати, що все добре лише тому, що негативних відгуків немає, хоча це може бути і не так. Ви повинні проявляти активність і перевіряти, чи справді вони використовували звіт і чи він слугував цілі, і використовувати дані, щоб налаштувати ваш спосіб спілкування; в іншому випадку ця прихована проблема може спричинити серйозні проблеми пізніше, коли їх важко виправити.

Приклад: Беріть на себе відповідальність

Легко звинувачувати інших у поганих результатах. Наприклад, ви, можливо, хочете, щоб ваша організація наділила вас повною мірою повноваження змінювати все в проекті та робити це досконало, але вони цього не роблять, і в результаті проект провалюється. Це не проактивний підхід.

Проактивний підхід полягає в тому, щоб брати на себе відповідальність і робити все можливе в рамках обмежень. Ви не можете сподіватися, що організація вам повністю довіриться і дасть вам все в надії отримати хороші результати, особливо коли вони побачили стільки невдалих проектів. Що вам потрібно зробити, це зробити одне невелике вдосконалення в рамках встановлених обмежень, використовувати це, щоб отримати трохи довіри, ще трохи ресурсів і трохи більше терпимості до обмежень, а потім використовувати це для трохи більшого вдосконалення, і виконуйте так, поки не досягнете оптимальної мети.


Пам’ятайте, що ланцюжок є настільки ж міцним, наскільки міцна його найслабша ланка

У проектах є різні складові, і всі вони потребують уваги; ми повинні мати цілісну перспективу проекту. Звернути увагу на, здавалося б, важливу складову (наприклад, час) недостатньо, тому що всі складові взаємодіють і вони не працюють належним чином, якщо всі вони не отримують належної уваги.

Приклад: Це все про дедлайнІ!

Скажімо, ви щось будуєте для Олімпійських ігор. Встановлено дуже жорсткий термін, що робить управління часом дуже важливим. Чи так це?

Що робити, якщо якість настільки низька, що потребує повторної роботи через деякий час. Це вплине на час, так що час та якість будуть потребувати додаткової уваги. У вас може бути сад фантазий, зазначений в оригінальному визначенні проекту, але ви знаєте, що якщо часу не вистачає, ви можете пропустити його і просто прикрити травою, якщо ви вчасно розглядали таку можливість і підготувались до цього. Отже, важливим є також управління змістом. Тепер у центрі нашої уваги зміст, час та якість.

Чи чули ви про той відомий приклад, коли президент Кеннеді зустрічається з двірником в НАСА і запитує його, що він робить, і двірник відповідає: “Я допомагаю посадити людину на Місяць”? Невже такий тип людей у проекті не допомагає дотриматись терміну?

Продовжуючи, ви помічаєте, що кожна окрема складова у проекті сприяє управлінню часом, і ви не можете дотриматись терміну з прийнятним рівнем визначеності, якщо не звернете увагу на всі складові.

Приклад: Вибіркові запозичення

Коли люди стикаються з різноманітними методами, іноді вони починають вибіркові запозичення та створюють поєднання всього, що здається цікавим з різних систем. Зазвичай це не працює, оскільки елементи не працюють ізольовано і повинні бути сумісні один з одним. Будь-які доповнення або зміни у системі повинні здійснюватися з цілісного погляду.

Ось чому ми іноді бачимо суперечливі елементи в різних методах; щось працює добре в одній системі, а його протилежність працює добре в іншій системі. Цей елемент не є правильним чи неправильним сам по собі.

Найбезпечніший підхід - це вибрати методологію для проекту, адаптувати її, а потім обережно додати до нєї нові елементи, враховуючи узгодженість елементів всієї системи.

Приклад: Антипроцесний підхід

Одна з найкращих речей, яку зробили Agile методи - вони привернули увагу до людських аспектів. Agile Manifesto надає більшої цінності для особистостей та взаємодій порівняно з процесами та інструментами, хоча це може бути не справедливим порівнянням. Практично всі методи кажуть, що людські аспекти важливі, і реальна відмінність методів Agile полягає в тому, що аспекти людини є вбудованою частиною їхніх процесів, а не простою пропозицією. Отже, мова йде не про конкуренцію між людськими аспектами та процесами, а про те, як бачать людські аспекти в системі.

Немає сумнівів, що деякі люди намагаються замінити людські аспекти більш складними процесами, але це лише неправильне використання. Навіть існує також зворотня ситуація: люди намагаються замінити процеси людськими аспектами, що теж не працює.

Приклад: Це всі необхідні вам складові

Розмірковуючи про складові, слід бути обережними, щоб не пропустити жодної з них. Хоча, які вони? Якщо ви перевірите фундаментальні джерела, ви отримаєте різні відповіді; і все ж, жоден з них не дасть повну відповідь.

PRINCE2® теми - це складові (домени), але це лише ті складові, які відіграють ключову роль у методології. Інші складові маються на увазі.

Керівництво PMBOK® не є методологією і може сформулювати відповідь набагато краще з десяти областей знань. Однак це інтерпретації всіх областей, що базуються на погляді Керівництва PMBOK® на проект, а не нейтральному (не те, що обов’язково існує нейтральна перспектива). Наприклад, людським аспектам не приділено багато уваги в Керівництві PMBOK®.

Хорошим джерелом інформації про складові є ICB (IPMA). Однак мова йде не про складові, а про компетенції, необхідні в проекті. ICB не має однозначних зіставлень з складовими, але ICB дуже допомагає їх ідентифікувати.

У NUPP відсутній список складових, насамперед тому, що це метасистема, а не система, а також тому, що категоризація складових залежить від типу проекту та його середовища; наприклад, звичайний проект будівництва може потребувати іншого погляду, ніж творчий дослідницький проект.


Не робіть нічого без чіткої мети

Нічого не слід робити, якщо це не має чіткої мети. Уявіть два паралельні світи, де все те саме, за винятком того, що ви думаєте робити: Наскільки би різними були ці світи? Чи варта різниця зусиль, щоб зробити це?

Якщо ви немаєте на увазі чіткої мети і ви робите лише щось, тому що всі інші це роблять, або всі кажуть, що це важливо робити, то

  • це може не мати реального зиску у вашому випадку, і тому ви можете нічого не отримати з цього; або
  • це може все-таки мати потенційні переваги у вашому випадку, але оскільки ви не маєте на увазі цілі, ваш спосіб її досягнення може не допомогти реалізувати переваги.

Приклад: Портфелі та програми

Якщо ви берете участь у виборі та ініціюванні проектів, вам слід переконатися, що ви бульше зосереджуєтесь на перевагах та проблемах, які потрібно вирішити, ніж на продукті, у якому будуть реалізовані рішення проблем та переваги. Класичний приклад - виробник ліфтів, який раніше отримував скарги на швидкість своїх ліфтів, і тому проводив безліч проектів для збільшення швидкості без повного успіху. Це тривало, поки вони не вирішили зосередитись на проблемі (нудьга чи дискомфорт людей) замість “природного” рішення (швидкі ліфти). У результаті було додано дзеркала до ліфтів, і це вирішило проблему просто і дешево.

Пам’ятайте, що управління проектами полягає в тому, щоб робити все правильно, тоді як управління портфелем - це робити правильні речі. Не важливо, наскільки добре ви керуєте своїми проектами; це не буде добре, якщо ви робите неправильні проекти. Вся справа в тому, щоб мати мету.

Приклад: Проект в цілому

Гнучкість продукту залежить від проектів. У деяких проектах розвитку ІТ продукт є абсолютно гнучким, і його остаточна форма залежить від зворотного зв’язку, який буде формуватися інкрементами продукту під час проекту, що вимагає адаптивного (Agile) підходу. Це практично з точки зору поєднання портфеля, програми та шарів проекту, і йому потрібно максимально приділяти увагу кінцевій меті. Добре задокументувати мету та мати її досяжною; це одна з цілей “продуктового бачення”, яка використовується в деяких Scrum проектах. Увага до ділових цінностей у проектах Agile - це спосіб їх узгодження з метою.

В інших типах проектів, де продукт відносно фіксований і існують інші механізми, які забезпечують, щоб ідентифікований продукт задовольнив мету, члени проектної групи можуть перенести значну частину своєї уваги з мети на продукт (отже, принцип “фокус на продуктах” PRINCE2®), але принаймні мінімальна увага до мети все ж потрібна для того, щоб те, що будується, задовольнило мету, це можна зробити, порівнюючи прогнозовані переваги з очікуваними вигодами (отже, принцип “постійного бізнес-обґрунтування” та тема “економічне обґрунтування” у PRINCE2®).

Коли проект працює для зовнішнього клієнта, у клієнта буде власна ціль проекту, а у вашої компанії інша ціль. Ви повинні розуміти і використовувати обидві цілі, щоб дійсно досягти успіху.

Приклад: Моніторинг проекту

Зосередження уваги на кінцевій цілі необхідно, але це може бути занадто абстрактно для багатьох щоденних завдань. Ось чому потрібна ієрархія драйверів, щоб зробити кінцеву ціль більш практичною. Спочатку обґрунтування та переваги проекту визначаються виходячи з кінцевої цілі, а потім у вас будуть явні та неявні цілі для показників проектів (наприклад, часу, вартості та якості), щоб задовольнити обґрунтування, що, в свою чергу, задовольнить кінцеву мету. Це цілі нижчого рівня, які корисні для багатьох наших щоденних завдань.

Що стосується моніторингу, моніторинг проекту на низькому рівні здійснюватиметься за допомогою показників найнижчого рівня, оскільки незавжди можливо відстежити кінцеву мету. У цьому випадку ви все ще повинні мати на увазі цілі: яка мета моніторингу?

Нормальною і прийнятною відповіддю є перевірка того, чи йдемо ми визначеним шляхом, а якщо ні, то викликати певну реакцію, яка поверне нас на колію або скоригує цілі та дасть побачити, чи можемо ми все ще задовольнити кінцеву мету. Таким чином, наші вимірювання повинні бути в змозі допомогти в цій цілі низького рівня, а відповідні вимірювання - це прогнози показників після завершення; наприклад, коли нам вдасться закінчити проект? Скільки коштів нам знадобиться для завершення проекту?

Усі інші вимірювання, такі як заплановані та фактичні значення на сьогодні, - це лише проміжні значення, які вам потрібні для обчислення прогнозів, а не кінцеві значення, які ви використовуєте для управлінських цілей.

Приклад: Документи

Незалежно від того, який підхід до розвитку ви використовуєте в проекті, планування завжди необхідно. Важливе питання - рівень деталізації у кожному типі плану. Якщо в плані недостатньо деталей, план не зможе зробити свій внесок, і виконання проекту буде базуватися на спеціальних рішеннях, а не на інтегрованих цілісних рішеннях. З іншого боку, багато людей намагаються бути обережними та додають занадто багато деталей до свого плану, що ускладнює підготовку та підтримку, і занадто жорстке для невизначеності проекту. В результаті план стає нереальним і марним.

Найкращий спосіб визначитися з рівнем деталізації - мати на увазі мету для кожного елемента плану. Наприклад, якщо ви розглядаєте можливість додавання ресурсів до плану, у вас повинна бути мета: Як ви його будете використовувати? Як це допоможе проекту? Скільки зусиль буде потрібно? і чи варто того?

Іноді справа в тому, щоб вирішити, чи хочете ви мати певний елемент у своїх планах, а іноді - про те, як ви хочете планувати чи підготувати щось. Будь то економічне обґрунтування, статут проекту чи звіт: ви все одно маєте запитати, чому ви готуєте цей документ і як він може допомогти проекту.

Шукати «шаблон» - це протилежне тому, щоб робити щось на основі мети.

Приклад: Звітність про хід віконання (статус)

У багатьох проектах зазвичай є дуже довгі звіти про статус. Виходячи з цього NUP, ми повинні запитати себе, яка мета звіту, і як ми можемо досягти цієї мети незалежно від того, що може робити більшість інших людей.

Це може, в багатьох випадках, змусити нас підготувати дуже прості звіти на одній сторінці, які зацікавлені сторони дійсно читають та розуміють замість довгих звітів. Це звертає увагу на мету.

Якщо ви готуєте звіти на одних сторінках, деякі люди можуть заперечити проти вас і вважати, що у вас немає «належної» системи моніторингу. На практиці це створює для вас другу мету (окрім першої мети, яка допомагає зацікавленим сторонам зрозуміти статус проекту), і для того, щоб задовольнити це, ви можете просто створити другий тип звіту, який дуже об’ємним. Однак ви не змішаєте це з першим звітом, оскільки ці дві цілі неоднакові.

Приклад: Бізнес-обґрунтування та статут проекту

Підготовка документів, таких як бізнес-кейси та статут проекту, як правило, є нудною, безрезультатною, бюрократичною необхідністю для більшості людей, хоча всі ці документи мають дійсні цілі, що стосуються більшості проектів. Якщо ви спробуєте знайти «шаблон» і заповнити його, робота просто витрачається; тоді як ви можете замість цього перевірити реальне призначення цих документів, побачити, чи вони можуть бути корисними для вашого проекту, а потім підготувати документ будь-яким способом, який вам подобається, просто для задоволення цих цілей: це буде правильний документ.

Хоча ви думаєте про те, як можна підготувати документи для задоволення їхніх цілей, ви можете не думати про кожен сценарій і може щось пропустити. Щоб уникнути цього, ви можете перевірити, що пропонують такі джерела, як PRINCE2®, PMBOK® Guide, і DSDM®, а потім оцінити ці пропозиції, виходячи з цілей.

Приклад: Постпроект

Хоча проект має конкретну мету, і ми можемо враховувати цю мету протягом усього проекту, реалізація мети в основному оцінюється на основі прогнозів, зроблених під час проекту. Однак ми не повинні забувати про це, коли проект буде закінчений. Важливо перевірити реалізацію цілей після завершення проекту, адже

ми можемо бачити, як досягаються кінцеві цілі та дізнаємось з них для майбутніх проектів, і

іноді цілі досягаються лише тоді, коли ми виконуємо деякі додаткові завдання після завершення проекту, і розуміння необхідності цих додаткових завдань потребує моніторингу.

Моніторинг після проекту - це необхідний крок у орієнтації на ціль. В основному це відповідальність систем управління програмами та портфелями, і оскільки більшість компаній не мають таких рівнів управління, цим кроком зазвичай нехтують. Ось чому такі методи, як та DSDM®, додають цей крок до своїх методологій управління проектами.

Приклад: Простота

Світ складний і хаотичний, але наші моделі - це абстрактні апроксімації, які відображають частини світу, а значить, вони можуть бути простими. З іншого боку, прості системи зазвичай працюють краще, оскільки ми можемо бути зосереджені на головній ідеї.

Багато хто з нас намагаються досягти кращих результатів, додаючи складність нашим системам, сподіваючись, що це буде відповідати складності світу, хоча на практиці це ускладнює роботу з системою і, як правило, блокує нас у задоволенні мети.

Приклад: Адаптація

Програмне забезпечення для потокової музики відрізняється від того, яке буде використовуватися для обладнання в лікарні або в літаку, де від програмного забезпечення може залежати життя людей, або від програмного забезпечення, яке буде використовуватися в супутнику, де воно має працювати багато років без збоїв, і всі вони відрізняються від будівництва літньої вілли, пожежної станції та технологічного заводу. Коли ви маєте на увазі цілі, ви краще зрозумієте, як адаптувати системи та артефакти для різних проектів.


Використовуйте повторювані елементи

Ad hoc підхід до проекту забирає занадто багато енергії та ресурсів і ви завжди ризикуєте втратити деякі необхідні елементи. Найкращий спосіб спростити те, що потрібно зробити, - це використовувати повторювані елементи та, бажано, застосовувати їх у повторюваних циклах.

Приклад: Контрольні списки якості

Контрольний список (чек-лист) - простий приклад потенційно повторюваного елемента, який багато людей використовують у особистому та професійному житті. Візьміть критерії якості товару, наприклад:

По-перше, ви можете створити контрольний список усіх критеріїв, що є формою планування.

Що рекомендує NUP6 - спробувати узагальнити: чи є в проекті подібні результати? У цьому випадку підготуйте загальний контрольний список якості для цієї категорії результатів та використовуйте їх для всіх. Якщо є деякі варіанти, збережіть загальний список та додайте кілька додаткових елементів для окремих результатів. Тепер у вас є повторювані контрольні списки.

Після того, як ви підготуєте загальні контрольні списки для різних видів результатів, ви можете знайти елементи, які повторюються серед них, що підказує для них віртуальну батьківську категорію. У такому випадку замість повторення елементів для всіх цих загальних контрольних списків ви можете їх витягнути і помістити в батьківський контрольний список. Зрештою, напевно, у вас буде єдиний загальний контрольний список для всього проекту. “Визначення зробленого” Scrum - приклад використання контрольних списків на рівні проекту для якості (можливо, серед іншого). Здійснюючи це, кожен результат буде належати до ієрархії категорій і повинен задовольняти позиції, що містяться в контрольних списках усіх категорій у їх ланцюжку.

Таким чином, елемент у батьківському контрольному списку стане повторюваним для всіх результатів, що знаходяться під ним, що економить час та енергію при плануванні та виконанні.

Що ще важливіше, коли ви зробите це для одного проекту, ви зможете адаптувати та використовувати його для всіх подібних проектів у майбутньому, що є повторюваною формою планування для декількох проектів.

Приклад: Процеси та робочі процеси

Деякі результати, або пов’язані з ними цілі, потребують певних кроків, які можуть стати стандартизованими та повторюваними. Наприклад, якщо результати повинні бути розроблені індивідуально та затверджені, ви можете підготувати простий робочий процес, який дозволяє зрозуміти всі кроки, залучених осіб та приблизну тривалість, щоб уникнути багатьох труднощів. Однак ви повинні бути обережними, щоб не зробити робочі процеси та процеси занадто складними або занадто інтенсивними в документації, оскільки це матиме негативний наслідок. Усі люди, які беруть участь у проекті, повинні сприймати робочі процеси та процеси як щось, що підтримує їхню роботу та полегшує для них все, а не як бюрократичну документацію, що блокує їх реальну роботу.

Agile проекти мають повторювані елементи у своєму ітеративному підході до розвитку, де певний тип розроблювальної діяльності повторюється для кожної фічі; напр. звичайний розпорядок дня в XP (програмування eXtreme): складіть пари, виберіть елемент, спроектуйте його на дошці, побудуйте тестові сценарії та код, інтегруйте код тощо.

Окрім повторюваних робочих процесів, які можна використовувати для технічної діяльності, ви можете мати повторювані елементи і для діяльності з управління проектами. Процеси в Керівництві PMBOK®, PRINCE2® та DSDM®, діяльності в та події в Scrum - приклади цієї концепції.

Приклад: Цикли

Маючи корисні елементи для управління проектом. Це можна зробити ще простіше, поміщаючи їх у повторювані цикли. Ці цикли значно спрощують повсякденну діяльність людей, задіяних в управлінні та керівництві проектом. Цикли груп процесів у Керівництві PMBOK® при використанні в проекті з декількома фазами, етапами PRINCE2®, щоденними, щотижневими та місячними циклами в, ітераціями та часовими рамками в DSDM® та спринтами в Scrum - є прикладами цієї концепції.

Коротші цикли легше зрозуміти та використовувати, ніж довші; наприклад, спринти в Scrum на відміну від фаз згідно з Керівництвом PMBOK®. Однак занадто коротких циклів може бути недостатньо для підтримки певних типів проекту, і рішенням може бути використання декількох циклів, таких як використання циклів коротких таймбоксів разом із тривалішими циклами ітерації DSDM® або ‘використання щоденних, тижневих та місячних циклів.

Приклад: Методи

Використання методології чи основи для запуску проекту - це ще одне використання повторюваних елементів. Це може бути існуюча система, наприклад PRINCE2®,, DSDM® або Scrum, або така, яку ви самостійно налаштували або побудували. Однак зазвичай краще почати з одного з існуючих методів і адаптувати його до ваших потреб, ніж будувати його з нуля.

Будь-який повторюваний елемент є абстрактним і потребує налаштування, щоб адаптувати його до реального світу. Хоча існує спектр абстрагування та необхідність в кастомізації: хоча невеликі, відносно конкретні контрольні списки якості знаходяться на одному кінці спектра з найменшою кількістю абстракцій та потребують адаптації, в той час як методології - з іншого, з найвищою потребою у адаптації. Ви завжди повинні відзначати необхідність адаптації, інакше повторюваний елемент не буде відповідати вашим потребам.


NUPP е колекция от почти универсални проектни принципи, които може да приложите във всеки проект за да има максимален успех, независимо от използваната методология или подход.

Всеки ресурс и метод по проектен мениджмънт обръща внимание на NUP / ПУП (почти универсални принципи), обаче:

  • Използващите тези принципи, трябва да ги разглеждат като едно цяло вместо като отделни принципи, и
  • Тези принципи не са достатъчно ясни като ресурси и повечето прилагащи ги са толкова ангажирани в практичните детайли за изпълнението им, че забравят за самите принципи и постъпват по начин, който не е съвместим с тях .

NUPP (ПУПП) са съвместими с основните методологии, ресурси и принципи като PRINCE2®, PMBOK® Guide,, PM², DSDM®, XP и Scrum. Въпреки, че NUPP (ПУПП) може да има разминаване с някои методологии, ПУПП насърчава използващите го да преусмислят техните тълкувания.


Бъдете ориентиране към постигане на резултати и истината за съпричастност

Хората имат вродена склонност да бъдат част от група, което, в повечето случаи, преминава отвъд основната идея да бъдеш част от нея, създава силно чувство за съпричастност и води до проблеми. Ние губим повече отколкото печелим в съпричастността си. Ние може да станем по-големи професионалисти и ефективни експерти, ако не органичаваме нашата индентичност и съпричастност с дадени групи.

Пример: Agile срещу Waterfall

Група от силно мотивирани хора, които били достатъчно смели да опитат да адаптивни подходи при в ИТ разработки, във времената, когато догмата била да се използват стандартните предсказуеми методи, се събрали и кръстили този метод Agile. Това би било страхотна инициатива, да не се ограничава избора в рамките на необходимото. Въпреки, че има много ентусиазирани и ориентирани към постигането на резултати хора в Agile общността, то все още има членове, които издигат Agile в култ и считат останалите за врагове. Това води до различни проблеми:

  • Не им позволява да научат нищо ново извън тяхната организация
  • Обезкуражава външни хора да научат нещо за тях
  • Превръща съпричастността към групата в нешо по-важно от реалната цел, което пречи да се разбере и осъзнае същносттна на Agile

Този проблем може да бъде значително намален, и дори разрешен, ако Agile не бъде използван единствено като етикет означаващ определен подход за разработка, а, по-скоро, като общност от хора, които считат себе си за създатели и лидери използващи Agile като средство за постигане на целите си, а не идентифицайраки се с него.

За истинския професионалист, войната Agile срещу Waterfall не същестува.

Пример: PRINCE2® vs. PMBOK®

Има много професионалисти в oбщността, които се асоциират или с Prince 2 или с PMBOK® методологията (обикновено, заради тяхното географско разположение) и съответно не са запознати с другия метод. Всеки от нас може да има предпочетания, но да не се индефицира с тях. По-важно е да се запознаем с другите методологии, за да разширим кръгозора и избора си от ресурси.

Истинският професионалист е отворен към всички идеи, търси ги, изучава ги, и ги използва, когато е необходимо без предрасъдъци и чувство за съпричастност.

Пример: Непрекъснато обучение

Съпричастността задоволява усещането на човека за принаджленост към дадена група и не го подтиква да учи, а понякога и го обезкуражава от страх да не бъде вече част от групата. Когато си свободен човек, експерт без принадлежност към дадена група, ти имаш нужда да запълваш недостатъците на дадената група със знания: с непрекъснато обучение.

Това, в което вярваме днес, не е истината. Това е само най-доброто ни възприятие и разбиране на нещата към момента, което трябва да развием за напред. Има нещо объркано, ако нечий идеи са съвсем същите, както са били преди няколко години. Дори с ПУПП: ако се върнем след няколко години назад и забележем, че принципите съвсем същите, трябва да бъдем мнителни.

Пример: Отвореност

Когато възразявате, постарайте се възражението ви да е насочено към идеята на човека, а не към самия него. Това спомага за избягването на напрежение. От друга страна, когато някой ви възразява, не го възприемайте като война, а като дискуия на идеята ви и отстането отворен (позитивен). Недейте да слушате, за да отговорите, а слушайте, за да разберете и работете с другия човек да доразвиете идеята.

Въпреки, че някои хора могат съзнателно да ви нападнат лично, вместо да обсъдят идеята ви. В такъв случай, преди да продължите, помогнете им да се концентрират върху идеята вместо върху вас и поддържайте фокуса по време на целия разговор.


Запазвайте и оптимизирайте ресурсите и енегията си

Ресурсите са органичени. Ресурсите за даден проект са ограничени, както е ограничена и менталната енергия необходима ви, за да взимате правилни решения. Трябва да запазите и оптимизирате този ресурс за себе си и за проекта, и да помогнете на другите членове на екипа ви да направят същото.

Пример: Правилото 80/20

Голяма част от възможните ползи от проектния мениджмънт могат да бъдат постигнати с малко усилия. В повечето случаи, стремежът да се реализират на 100% от възможните ползи е много скъпо и неоправдано. Трябва да се възползвате от това правило във всичко което правите и да насърчавате останалите да правят същото.

Пример: Умора от вземането на решения

Ние имаме един източник на ментална енергия за вземането на решения, както и за запазване на самообладание. Ако използваме прекалено много от енергията си за вземане на ненужни или несъществени решения, ще имаме по-малко сили при вземането на важни решения, което може да доведе до слаби резултати. Това е една от причините да се избягва микро-мениджмънта (принципът на „управление на изключенията“ според Prince2 the “manage by exception” principle of PRINCE2®).

Подлагането на дадена идея под съмнение може да бъде полезно, но конфронтирането с хора, обикновено, е погабно за проекта. Едно от последствията е, че може да изцеди менталната енергия на хората от екипа. Ако забележете такова конфронтиране между хора от екипа, трябва да направите всичко възможно да откриете и да я отсраните.

Пример: Грижете се за себе си

Менталната ви енергия се изчерпва, когато взимате решения и запазвате самообладание. От друга страна, енергията се възстановява при правилно хранен и здрав сън. Следователно, трябва да се грижите са себе си: спете достатъчно, за да бъдете отпочинали и се хранете правилно. Ако имате вредни навици или проблеми със съня, може да се обърнете за съвет към специалисти в тези сфери. Физическата активност също може да ви помогне с набавянето на ментални сили, въпреки че проучванията не са катергорични в тази насока.

Опитвайте се да мотивирате членовете на екипа да правят същото. Първо, погрижете се да работят с постояннно темпо и без много допълнителни часове. След това, ако имате избор, опитайте да предложите здравословна храна и напитки по време на работния процес.

Пример: Баланс между работа и личен живот

Повечето от нас обичат това, с което се занимават, но това не е всичко, от което се нуждаем в живота. За да направим личният си живот щастлив и забавен, можем да използваме идеи и опита си при планиране и оптимизиране на служебния такъв. Когато сте по-щастливи, може да сте и по-успешни в работата си. Ако имате възможност насърчавайте екипа си да прави същото.

Пример: Мотивация

Мотивацията е сложна сфера. Има много интересни и полезни източници по темата, дори и много ненаучни трудове. Въпреки това, трябва да сте запознати с мотивационната теория и да я използвате непрекъснато, защото тя може да повиши менталните сили на хората от екипа и да помогне за постигането на по-добри резултати за проекта.

Мотивирането може да се изрази като просто покажем, че оценяваме труда на колегите си за добре свършената работа с приятелска усмивка или едно „Благодаря“. Трябва, обаче, да бъдем предпазливи, защото понякога някои мотивационни стимули като финансовия, могат да имат отрицателен ефект.

Пример: Сътрудничество и работа в екип

Хората, които си сътрудничат често могат да постигнат по-добри резултати, но по-важното, е че по този начин те са социални и са доволни да бъдат част от група. Ако успеете да премахнете отрицателните аспекти от работата в екип и да създадете благоприятни условия на труд, ще има много по-доволни хора в екипа ви.

Трябва да сте внимателни, защото хората са различни и някои имат нужда от повече почивка, по-голяма концентрация, повече социализиране от други, поради тази причина трябва да намерите баланса.

Пример: Култура на единен екип

Има тенденция да се формират по-малки работни (под)групи от заинтересованите лица създава напрежение между тях: например, финансово ориентираните служители срещу служителите, които произвеждат/разработват продукта. Това напрежение отнема много енергия и на двете страни, което е една от причините, поради която ние трябва да изградим култура на единен екип, където всички работят заедно за постигането на обща цел.

Пример: Мъдростта на тълпата

Когато различни хора работят като екип в подходяща среда, потенциално могат да се постигнат много добри резултати, идеи и решения, които даже да са по-добри тези идващи от даден експерт.

Ако имате тази възможност, събирайте екипа си регулярно, за да ви помагат при вземато на трудни решения за проекта. Освен възможността да постигнете по-добри резултати, това показва, че оценявате мнението на хората от екипа и те играят важна роля в проекта, което покачва тяхната мотивация и дух. Дейност №26 от е добър пример за използване на мъдростта на тълпата.

Пример: Главен проектен посредник

Ако сте ръководител проект, повечето от нещата, които правите имат посреднически характер (или поне би трябвало). От друга страна, може да забележите, че хората са имали предишен опит с други мениджъри, който влияе върху сегашните ви взаимоотношения: част от енергията им отива в това да анализират поведението ви за потенциални опасности вместо да ви имат доверие. В този случай, може да си смените титлата на Главен проектов посредник. В крайна сметка, това е ролята, която изпълнявате в рамките на проекта.


Винаги бъдете инициативни

По природа имаме склонност да реагираме на дадени неща и ситуации. Това може да ни помогне да запазим енергия занимавайки се с незначителни неща или да постигнем по-добри резултати в област, в която сме напълно некомпетентни. Тези ситуации са различни от нашите проекти и точно в тях, може да постигнем по-добри резултати бъдейки инициативни.

Пример: Планиране

Ако искате да стигнете до непозната локация с кола и закъснявате, то може просто да се качите в колата и да започнете да карате, за да „спестите време“, а да се справяте с евентуалните проблеми по време на пътя (в движение). Проактивният подход е да отделите време в началото, за да настроите навигацията си и тя да ви даде най-бързия път базирайки се на трафика и потенциалните инциденти и задръствания и чак след това да тръгнете на път. Така отделяме време в началото, за да избегнем потенциални проблеми повреме на изпълнението, което накрая води до спестено време.

В противовес на това, което някои хора мислят за Agile проектите, планирането е винаги необходимо, но е въпрос на вид и степен на детайлност в плана. Да планираме преди да пристъпим към изпълнение е проактивен подход.

Припомнете си цитата: Дайдете ми 6 часа да отрежа дърво и аз ще отделя първите четири часа да наточа брадвата.

Ако целта на проекта е ясна и сте сигурни, че трябва да се нареже дърво, то наистина може да отделите 4 часа, за да наточите брадвата. В Agile проектите, не е сигурно, че ще трябва да се нареже дърво или да се съберат отсечените клони или да се окоси тревата или нещо друго. Въпреки това, ще ви е необходима обща подготовка за всички дейности (да знаете къде е най-близкият магазин за резервни части) и малко специфична подготовка (заточване), преди да се фокусирате върху конкретни решения; това е планиране.

Пример: Планиране на планирането

Планиране на начина, по който ще се осъществи проектът е проактивен подход. Тази проактивност може дори да бъде разширена като се планира начина, по който планираме изпълнението на проекта: Според PMBOK® тове е проектния план, според PRINCE2® това са мениджърските стратегии, а според DSDM® това са подходите.

Пример: Непрекъснато планиране

В действителност нещата рядко се получават така, както сме ги планирали, и това е нормално, но ние непрекъснато трябва да адаптираме плановете, за да са реалистични, практични и реализируеми в действителност. Ние трябва да направим промяната в момента, в който е необходима, а не когато вече имаме проблем. Това е проактивен подход.

Пример: Управление на риска

Идеята за управление на риска е базирана на проактивност: при материализирането на несигурни събитие, предварително обмислете възможните последствия и възможните реакции и, съответно, какви действия да предприемете преди да се е случило събитието, вместо да чакате да видите какви ще са последствията, за да предприемете коригиращи действия.

Не забравяйте, че това което правим в проектите е сериозно и дори понякога е крие риск за живота на хора.

Пример: Определете ролите и отговорностите

Може да оставите екипа си да работи без да има ясни роли и отговорности (длъжностни характеристики), и рано или късно дадени роли и отговорности ще се обединят, но това може да струва прекалено скъпо за проекта и, в крайна сметка, да няма положителен ефект. Проактивният подход е да определите ролите и отговорностите в ранен етап на проекта и да ги адаптирате спрямо ситуацията. Това ще подобри работния процес на всеки от екипа, и ще му помогне да се фокусира върху изпелнението на поставените задачи вместо да се разпределя коя задача трябва са се свърши и от кого.

Броят на ролите и тяхното разнообразие зависи от проекта; може да е опростен вариант както при SCRUM, не сложен вариант като при P3.Express или нещо сложно както при DSDM® и Prince2. Не забравяйте, че тези подходи са за определяне на управленските дейности, в допълнение, трябва да се дефинират и техническите характеристики на ролята.

Пример: Избор

Трябва ли да прекратите проекта преждевременно или да продължите?

Рядко има само две възможности, дори и въпросът да загатва за това. Трябва да имате проактивен подход и да обмислите всички възможности преди да вземете решение. Може да преразгледаде обхвата на проекта, може да го преустановите докато не се изясни нещо, или може би да промените подхода за изпълнение (например: аутсорсване) или друго.

Пример: Критично мислене

Всички имаме някакви предрасъдъци, които, от една страна, ни помагат да оцеляваме, но от друга могат да ни подведат да вземем лошо решение. Когато става въпрос за вземане на важни решения за проекта, най-добре е да направим малка пауза за известно време и да обмислим всички предпоставки, които биха повлияли нашето решение преди да предизвикат проблеми.

За справка може да използвате списъка за когнитивни предрасъдъци в Wikipedia:

Има и методология за вземане на решение, която може да ви помогне. Отначало, може да е разсейващо и дори дразнещо, когато ги употребявате, но след известно време ще свикнете и в последствие ще се научите да извличате ползите от тях без да ви представлява усилие.

Пример: Прозрачност

Не ни е приятно когато задачите по проекта се изпълняват със закъснение или имаме проблеми при изпълнението, но това не означава, че трябва да ги скрием. Трябва да бъдем прозрачни и да информираме заинтересованите страни, защото някои от тях може да са в състояние да ни помогнат и освен това, рано или късно те ще узнаят за проблемите и техните последствия, а за някои от тях ще са необходими по-ранни противодействия (например: за да се приемат негативните последствия).

Пример: Ефективна комуникация

Вероятно е имало случаи, когато сте изпращали отчети до заинтересованите страни и не сте получавали обратна връзка. Може би сте вярвали, че всичко е наред само, защото не е имало негативна реакция макар, в действителност, да не е било така. Трябва да бъдете проактивен и да проверите дали отчетът е бил видян и дали е постигнал целта, да използвате обратна връзка за да подобрите комуникацията. В противен случай, този потенциално скрит проблем може да причини сериозни проблеми на по-късен етап, когато е по-трудно да бъде разрешен.

Пример: Поемете отговорност

Лесно е да се обвиняват другите за слабатие резултати. Например, може да искате фирмата да ви даде цялата власт да промените всичко по проекта и да го направите идеално, но не я получавате и като резултат проектът се проваля. Това не е проактивен подход.

Проактивният подход е да поемете цялата отговорност и да направите всичко по силите ви, въпреки ограниченията. Не очаквайте фирмата да ви гласува пълно доверие с надеждата да подобрите резултатите, след като вече са имали толкова провалени проекти. Това, което трябва да направите е да внесете подобрения въпреки ограниченията, да спечелите доверие и така стъпка по стъпка да достигнете до желаната в началото цел.


Не забравяйте, че една верига е толкова силна, колкото най-слабото й звено

Има различни области при управлението на проекти и всички те се нуждаят от внимание, т.е необходимо е да имаме цялостен поглед върху проекта. Фокусирането върху една привидно важна област (напр. Време) не е достатъчно, тъй като всички области си взаимодействат и не работят правилно, освен ако не получат адекватно внимание.

Пример: Всичко опира до крайния срок!

Да предположим, че изграждате нещо за Олимпийските игри. Спазването на крайния срок е от изключително значение, което прави управлението на времето много важно. Но дали е така?

Какво ще стане, ако качеството на работа е толкова ниско, че изисква тя (или части от нея) да се повторят след време. Това ще се отрази на времето, така че нещата вече опират до време и качество. Може да имате фантастична градина включена в първоначалната дефиниция на проекта, но знаете, че ако няма достатъчно време, можете да я пропуснете и просто да я покриете с трева, стига да сте обмислили тази възможност навреме и да сте се подготвили за нея. Така че, управлението на обхвата също е важно. Сега вече имаме областите на обхвата, времето и качеството в центъра на нашето внимание.

Чували ли сте за този известен пример, когато президентът Кенеди се среща с чистач в НАСА и го пита какво прави, а той отговаря: „Аз помагам да се изпрати човек на Луната“. Дали и този тип хора в проекта не спомагат за спазването на крайния срок?

Докато напредвате забелязвате, че всяка отделна област в проекта допринася за управлението на времето и не бихте могли да спазите крайния срок с приемливо ниво на сигурност, освен ако не обърнете внимание на всички области.

Пример: Подбиране на най-доброто (черешката на тортата)

Когато хората се сблъскат с различни методи, понякога започват да подбират най-доброто (черешката на тортата) от всеки и създават комбинация от виско което исглежда интересно от различните системи. Това, обикновено, не работи, защото елементите не работят изолирано и трябва да са съвместими един с друг. Всякакви допълнения или промени в системата трябва да се правят от гледна точка на цялото.

Ето защо понякога виждаме противоречиви елементи в различни методи, т.е. нещо работи добре в една система, а противоположното му работи добре в друга система. Този елемент сам по себе си не е правилен или грешен.

Най-сигурният подход е да се избере методология за проекта, да се приспособи за него, и след това предпазливо да се добавят нови елементи, като се вземе предвид съвместимостта на цялата система.

Пример: Подходът на антипроцеса

Едно от най-добрите неща, които Agile методологиите са направили, е да привлекат вниманието към човешките аспекти. Манифеста за Agile разработка отдава по-голямо значение на индивидите и взаимодействията между тях в сравнение с процесите и инструментите, въпреки че това може да не е справедливо сравнение. Почти всички методологии казват, че човешките аспекти са важни, а истинската разлика в Agile методологията е, че човешките аспекти са част от процесите, а не просто предположение. Така че не става въпрос за конкуренция между човешките аспекти и процеси, а по-скоро за начина, по който човешките аспекти се разглеждат в системата.

Няма съмнение, че някои хора се опитват да заменят човешките аспекти, като прилагат по-сложни процеси, но това е само злоупотреба. Дори обратното: хората се опитват да заменят процесите с човешки аспекти, което също не работи добре.

Пример: Това са всички необходими области

Когато мислите за областите, трябва да внимавате да не пропуснете нито една от тях. А какви са те? Ако проверите основните източници, ще получите различни отговори и, все пак, никой от тях не дава цялата истина.

Темите на PRINCE2® са области, но това са само областите, които играят ключова роля в методологията. Другите области са само подразбиращи се.

PMBOK® ръководството не е методология, но много добре описва десет области на познание. Според него, обаче, това са интерпретации на всички области, което не е непременно неутрална гледна точка. Например, човешките аспекти не получават много внимание в PMBOK® ръководството.

Добър източник на информация за областите е ICB (IPMA Competence Baseline), въпреки че не става въпрос за области, а за компетенциите, които се изискват в проекта. Тези компетенции нямат еднозначна връзка с областите, но много помагат при идентифицирането им.

Няма списък с области и в ПУПП, главно, защото е мета-система, а не система, а също така и защото категоризацията на областите зависи от вида на проекта и неговата среда. Например, един рутинен строителен проект може да се нуждае от различен подход и гледна точка в сравнение с един творчески изследователски проект.


Не правете нищо без ясна цел

Не бива да правите нищо, освен ако нямате ясна цел. Представете си два паралелни свята, където всичко е същото, с изключение на това, което смятате да правите. Колко различни биха били тези светове? Дали разликата си струва усилието да се направи това което смятате да правите?

Ако нямате ясна цел и само правите нещо, защото всички останали го правят или всички казват, че е важно да го направите, то:

  • може да няма реална полза от него във вашия случай и следователно да не получите нищо от това или
  • все пак, може да има потенциални ползи във вашия случай, но тъй като не сте целенасочени, това което правите и начина по който го правите може да не доведе до реализиране на ползите.

Пример: Портфолио и програми

Ако участвате в подбора и инициирането на проекти, трябва да се уверите, че се фокусирате върху ползите и проблемите, които трябва да бъдат решени, а не върху продукта, който ще реализира тези неща. Класическият пример е производителят на асансьори, който тъй като получавал оплаквания за скоростта на своите асансьори инициирал и ръководил множество проекти за увеличаване на скоростта, без пълен успех. Това продължило докато не решили да се съсредоточи върху проблема (скуката или дискомфорта на хората) вместо с „естественото“ решение (по-бързи асансьори). Резултатът е, че те добавят огледала в асансьорите и решават проблема просто и евтино.

Не забравяйте, че в управлението на проекти става въпрос основно да правите нещата правилно, докато управление на портфолио е за правене на правилните неща. Няма значение колко добре управлявате проектите си, тъй като това няма да работи добре, ако правите грешни проекти. Всичко опира до това да имате цел.

Пример: Проектът като цяло

Гъвкавостта на продукта варира между проектите. В някои ИТ проекти продуктът е напълно гъвкав и неговата окончателна версия зависи от обратната връзка, която ще бъде генерирана на всеки етап от разработката му по време на проекта, което изисква адаптивен (Agile) подход. На практика това е комбинация от наслояване на портфолио, програма и проект и се нуждае от максимално внимание към крайната цел. Добра идея е да се документира целта и тя да бъде достъпна. Това е една от целите на „продуктовата визия“, използвана в някои Scrum проекти. Вниманието към стойността на бизнеса в Agile проектите е техният начин да осигурят съответствие с целта.

В други видове проекти, където продуктът е относително фиксиран и съществуват други механизми, които да гарантират, че идентифицираният продукт ще задоволи целта, членовете на екипа на проекта могат да прехвърлят голяма част от фокуса си от целта към продукта (следователно, принципът „фокус върху продуктите“ на PRINCE2®). Минималното внимание към целта, обаче, все още е необхоидмо, за да се гарантира, че това, което се разработва, ще задоволи целта, което може да бъде направено чрез сравняване на прогнозираните ползи с очакваните ползи (оттук и принципът на „продължаващата бизнес обосновка“ и темата „бизнес казус“ в PRINCE2®).

Когато даден проект се изпълнява за външен клиент, то той ще има своя собствена цел за проекта, а вашата компания ще има различна цел. Трябва да разберете и да следвате и двете, за да успеете наистина.

Пример: Мониторинг на проекта

Необходимо е да се фокусираме върху крайната цел, но, в повечето случай, в ежедневието тя може да бъде твърде абстрактна. Ето защо, за повече практичност, е необходима йерархия на целите. Първо, обосновката и ползите от проекта се дефинират въз основа на крайната цел, което ще ви даде ясни и подразбиращи се цели за променливите на проекта (напр. време, разходи и качество), които да удовлетворят обосновката, която от своя страна ще удовлетвори крайната цел. Това са цели от по-ниско ниво, които са полезни за много от ежедневните ни задачи.

Когато става въпрос за мониторинг, мониторингът на проекта на ниско ниво ще се извърши, като се използва най-ниското ниво на променливите, тъй като може да не е възможно да се проследи крайната цел. В този случай все още трябва да имате предвид целите: каква е целта на мониторинга?

Нормален и приемлив отговор е да видим дали се движим по план и, ако не, да предизвикаме определена реакция, която ще ни върне обратно в норма. В противен случай ще коригираме целите и ще видим дали все още можем да задоволим крайната цел. Следователно нашите измервания трябва да могат да помогнат с целта на ниско ниво, а подходящите измервания, от друга страна, дават прогнози за променливите накрая. Например, кога ще можем да завършим проекта? Колко пари ще ни трябва, за да приключим проекта?

Всички други измервания, като планираните и действителните стойности до момента, са само междинни стойности, които са ви необходими, за да изчислите прогнозите, а не крайните стойности, които използвате за управленски цели.

Пример: Документи

Без значение какъв подход за управление използвате в проекта, планирането винаги е необходимо. Важният въпрос е нивото на детайлност във всеки вид план. Ако няма достатъчно подробности в него, то той няма да бъде достатъчно полезен, а изпълнението на проекта ще се основава на временни решения, а не на интегрирани и цялостни такива. От друга страна, много хора се опитват да бъдат предпазливи и да добавят прекалено много подробности към своя план, което го прави твърде труден да се подготви и поддържа и твърде строг за несигурността на проекта. В резултат на това планът става нереалистичен и безполезен.

Най-добрият начин да се определи нивото на детайлност е да определите по една цел за всеки елемент в плана. Например, ако обмисляте добавянето на ресурси към плана, то трябва да имате цел за това: Как ще ги използвате? Как ще помогнат на проекта? Колко усилия ще им отнеме? Струва ли си?

Понякога трябва да решите дали искате да имате определен елемент в плана си, а понякога и за начина, по който искате да планирате или подготвите нещо. Независимо дали става дума за бизнес случай, за харта на проекта или за доклад, винаги трябва да се запитате защо подготвяте този документ и как той може да помогне на проекта.

Търсенето на „шаблон“ е обратното на правенето на нещо, което се основава на цел.

Пример: Отчитане на състоянието

Често се случва да създадем наистина дълги отчети за състоянието на проекта. Въз основа на този ПУП трябва да се запитаме каква е целта на отчета и как можем да постигнем тази цел, независимо от това, което повечето други хора биха направили.

В много случаи това може да ни накара да подготвим прости отчети от една страница, които заинтересованите страни наистина да прочетат и разберат, вместо дълги такива. Това обръща внимание на целта.

Ако подготвите отчет на една страница, обаче, някои хора могат да възразят срещу вас и да помислят, че нямате подходяща система за наблюдение. На практика това създава за вас втора цел (освен първата цел, която помага на заинтересованите страни да разберат статуса на проекта) и, за да я задоволите, може просто да създадете втори тип доклад, който е дълъг. Въпреки това няма да го смесвате с първия, защото тези две цели не са еднакви.

Пример: Бизнес казус и харта на проекта

Подготовката на документи като бизнес казус и проектна харта обикновено е скучна, безплодна, бюрократична необходимост за повечето хора, докато тези документи имат валидни цели, които се прилагат за повечето проекти. Ако се опитате да намерите „шаблон” и да го попълните, усилието е просто пропиляно. Като се има предвид, че вместо това можете да проверите истинската цел на този документ, да видите дали и как той може да бъдат полезен за вашия проект, и след това да го подготвите по какъвто желаете начин, само за да удовлетворите тези цели, то това ще бъде правилният документ.

Докато мислите за начина, по който можете да подготвите документите, за да задоволите техните цели, може да не мислите за всеки сценарий и да пропуснете нещо. За да избегнете това, можете да проверите какви ресурси предлагат PRINCE2® , PMBOK® ръководстворо, и DSDM® и след това да оцените тези предложения въз основа на целите.

Пример: Пост-проект

Въпреки че проектът има конкретна цел и ние можем да я разгледаме по време на проекта, реализирането й се оценява основно въз основа на прогнозите, направени по време на проекта. Не трябва обаче да забравяме за това, когато той приключи. Важно е да се провери реализацията на целите след приключване на проекта, защото

  • можем да видим как са постигнати крайните цели и да използваме наученото при бъдещи проекти и
  • понякога целите се постигат само когато изпълним някои допълнителни задачи след приключването на проекта, а разбирането на необходимостта от тези допълнителни задачи се нуждае от мониторинг.

Мониторингът след приключване на проекта е необходима стъпка за постигане на целта. Това е основна отговорност на системите за управление на програми и портфолио и, тъй като повечето компании нямат такива нива на управление, тази стъпка обикновено се пренебрегва. Ето защо методи като и DSDM® добавят тази стъпка към техните методологии за управление на проекти.

Пример: Простота

Светът е сложен и хаотичен, но нашите модели са абстрактни приближения, които отразяват части от света и следователно могат да бъдат прости. От друга страна, простите системи обикновено работят по-добре, защото можем да се фокусираме върху основната идея.

Много от нас се опитват да постигнат по-добри резултати, като добавят сложност към нашите системи, надявайки се, че това ще съответства на сложността на света, въпреки че на практика това прави системата трудна за работа и, обикновено, ни пречи да изпълним целта.

Пример: Приспособяване

Част от софтуер за стрийминг на музика, например, има много различни условия за разработка и управление на проекта от тези, които ще се разглеждат при оборудване в болница или на самолет, където животът на хората може да зависи от продукта, или пък от софтуер, който ще се използва в сателит, който се предполага, че ще работи много години, без да се срине. И всички те са различни от изграждането на лятна вила, противопожарна станция и технологичен завод.

Когато имате предвид целите, ще разберете по-добре как да приспособите системите и артефактите при управлението на различни проекти.


Използвайте повторяеми елементи

Моментният (ad hoc) подход към проекта отнема твърде много енергия и ресурси, при което рискувате да пропуснете някой от необходимите елементи. Най-добрият начин за опростяване на това, което трябва да се направи, е да се използват повтаряеми елементи и, за предпочитане, в повтарящи се цикли.

Пример: Контролни списъци за качеството

Използването на пълен списък за бърза справка е прост пример за потенциално повтаряем елемент, който много хора използват в личния и професионалния си живот. Вземете критериите за качество на даден краен продукт или услуга, например:

  • Първо, можете да създадете пълен списък с всички критерии, което е форма на планиране.
  • Това, което ПУП6 препоръчва, е да се опитате да обобщите ситуацията: има ли сходни продукти или услуги, върху които да работите повреме на проекта? В такъв случай подгответе общ контролен списък за тази категория продукти или услуги и го използвайте за всички. Ако има някои вариации, то запазете общия списък и добавете няколко допълнителни елемента за отделните случаи. Сега имате повторяеми контролни списъци.
  • След като подготвите общите контролни списъци за различни видове продукти/услуги, можете да намерите елементи, които се повтарят сред тях, което предполага мета категория. В този случай, вместо да повтаряте елементите за всички тях, можете да ги обобщите и да ги поставите в главен контролен списък. В крайна сметка, вероятно ще имате един общ контролен списък за целия проект. „Дефиницията на завършено“ от Scrum е пример за използване на контролни списъци за качество на ниво проект (възможно е и използването му за други неща). Правейки това, всеки продукт или услуга ще принадлежи към йерархия от категории и трябва да удовлетворява елементите от контролните списъци на всички категории в тяхната верига.

По този начин един елемент от главения контролен списък ще стане повторяем за всички продукти или услуги под него, което спестява време и енергия при планирането и изпълнението.

По-важното е, че след като направите това за един проект, можете да го приспособите и да го използвате за всички подобни проекти в бъдеще, което е повторяема форма на планиране за множество проекти.

Пример: Процеси и работни потоци

Някои продукти или услуги или цели свързани с тях се нуждаят от определени стъпки, които могат да станат стандартизирани и повтаряеми. Например, ако продуктите или услугите трябва да бъдат проектирани индивидуално и одобрени, то можете да разработите прост работен поток, който изяснява всички стъпки, заинтересовани лица и приблизително времетраене, така че да се избегнат много трудности. Трябва, обаче, да внимавате да не правите работните потоци и процеси твърде сложни или твърде бюрократични, тъй като това би имало негативни последици. Всички хора, участващи в проекта трябва да приемат работните потоци и процеси като нещо, което подпомага тяхната работа и прави всичко по-лесно за тях, а не като бюрократична документация, която блокира дейността им.

Гъвкавите проекти имат повторяеми елементи в техния итеративен подход на разработване, където някои видове дейности при разработката се повтарят за всяко изискване. Например, обичайната рутинна работа в XP (eXtreme Programming): свържете, изберете елемент, проектирайте го на бяла дъска, изградете тестови скриптове и код, интегрирайте кода и т.н.

Освен повтарящите се работни потоци, които могат да се използват за оперативни дейности, може да имате и повторяеми елементи за дейностите по управление на проекти. Примери за тази концепция са процесите в PMBOK® ръководството, PRINCE2® и DSDM®, дейностите в и събитията в Scrum.

Пример: Цикли

Изготвянето на повтарящи се елементи за управление на проекта е полезно. Това може да се направи още по-лесно, като тези елементи се поставят в повторяеми цикли. Тези цикли значително опростяват ежедневните дейности на хората участващи в управлението и ръководенето на проекта. Всички примери за това понятие са: циклите на групите от процеси в PMBOK® ръководството, когато се използват в проект с множество фази; етапите в PRINCE2® ; дневните, седмичните и месечните цикли в; итерациите и времевите кутии в DSDM® и спринтовете в Scrum.

По-кратките цикли са по-лесни за разбиране и използване от по-дългите. Например, спринтовете в Scrum за разлика от фазите, съгласно PMBOK® ръководството. Въпреки това, цикли, които са твърде кратки, може да не са достатъчни при определени видове проекти. Решение на това може да бъде използването на няколко цикъла, като употребата на кратки времеви цикли при DSDM® заедно с по-дълги поетапни цикли или използване на ежедневни, седмични и месечни цикли при

Пример: Методи

Друг пример за употреба на повторяеми елементи е използването на методология или рамка за изпълнение на проекта. Това може да бъде съществуваща система като PRINCE2® ,, DSDM® , или Scrum, или такава, която да приспособите или изградите сами. Обикновено е по-добра идея да започнете с един от съществуващите методи и да го адаптирате към нуждите си, отколкото да го изградите от нулата.

Всеки повтарящ се елемент е абстрактен и се нуждае от приспособяване, за да се адаптира към реалния свят. Можем да говорим за спектър от абстракция и необходимост от приспособяване, където в единия край на спектъра с най-малко абстракция и необходимост от приспособяване са малки, относително конкретни контролни списъци за качество, а методологиите са на другия край, с най-голяма нужда от приспособяване. Винаги трябва да обърнете внимание на необходимостта от приспособяване, в противен случай повторяемият елемент няма да отговаря на вашите нужди по подходящ начин.

discussion icon NUPP is open-source and published for free under a Creative Commons license.

discussion icon Share your opinion or ask questions on this LinkedIn page.

discussion icon Written by: Nader K. Rad

discussion icon Translated to Arabic by Afef Mezzi

discussion icon Translated to Belarusian by Kristina Mozhei and Dmytro Lukianov

discussion icon Translated to Chinese by 黄宏

discussion icon Translated to Dutch by Damien Camerman and Elke Spinnewyn

discussion icon Translated to French by Gerard Olushola ODJE and Susanna Cobucci

discussion icon Translated to Greek by Theodoros Argyriou

discussion icon Translated to Italian by Cristiano Ottavian and Marco Caressa and Susanna Cobucci

discussion icon Translated to Norwegian by Barbro Moen Ternsten

discussion icon Translated to Persian by Mehrzad Mansourzadeh

discussion icon Translated to Russian by Dmitry Ilienkov and Valeriya Kapustina

discussion icon Translated to Serbian by Vladimir Majstorovic

discussion icon Translated to Spanish by Sabrina Stephens

discussion icon Translated to Ukranian by Hanna Lytvynchenko

discussion icon Translated to Bulgarian by Alexander Petkov and Aneliya Chervenova