POTI: A Model for Programme Blueprints
Posted by Elizabeth
The OGC’s Managing Successful Programmes (MSP) framework uses a categorisation process to identify areas of scope that should be considered by the programme Blueprint.
A Blueprint is a detailed vision for the organisation, covering what the organisation will look like when all the projects are completed, the programme is wound up, and the business transformation is done. Typically, you would only write a Blueprint at programme level, so project managers will ‘inherit’ a Blueprint from their programme manager. If you are leading a project as part of a bigger initiative being managed as a programme, ask to see the Blueprint if you haven’t already. It will help set your project in the wider context of what the business is trying to achieve.
In particular, Blueprints use the POTI model as a way to define the scope of what is going to change once all the projects in the programme are complete. POTI sets out the scope of the programme at a high level.
POTI stands for Processes, Organisation, Technology and Information. These four areas make up a comprehensive view of all the elements that form the programme scope.
Delegate and escalate: two important skills
Posted by Elizabeth
When you kick off a project, you should know how you are going to get things done. You’ll have processes in place for many things already, thanks to your PMO, or as a result of having done them before. However, do you have a clear approach for delegation and escalation?
Delegation and escalation are two sides of the same coin. Delegation is giving work to someone in your team or maybe on the same hierarchical level as you. Escalation is giving work to someone above you, such as the project sponsor. The same principles apply for both task allocation exercises. The person receiving the tasks needs:
- Clear instructions on what to do with it
- A deadline by when you need it done
- An appreciation of what will happen if it doesn’t get done i.e. setting the task in the wider context of the project.
When Leadership is Lacking
Posted by Brad Egeland
Leadership, not just project management, is critical on all projects. Whether it comes just from the project manager – where it must be prevalent – or from others on the project team … leadership is very important. The problem is, it is often lacking on some of the projects that need it the most.
The reasons for this are many, and are worth noting…. please read on…
There is a tendency to select people solely for their technical expertise. While expertise is important, it is a mistake to assume that expertise is equivalent to leadership. Leadership goes beyond technical prowess, increasingly recognized as subordinate to other qualities. Often, a person selected for his or her technical expertise relies on that quality at the expense of the project.
There is a failure to distinguish between project leadership and project management. Project management deals with the mechanics of managing a project, such as building a schedule; project leadership deals with much bigger issues—for example, ensuring that people focus on the vision.
There is a tendency to wear blinders. In a complex, constantly changing environment, many project managers seek security by grabbing on to a small piece rather than looking at the big picture. They may focus, for example, solely on technical issues or on the schedule at the expense of more important areas.
There is a tendency to be heroic. That is, they try to do everything themselves and be all things to all people. They eventually start to over control and in the end, as many experienced project managers know, control very little, even themselves. They fail, for example, to delegate.
Negotiating for Specifications and Resources on the Project
Posted by Brad Egeland
In general, project manager will conduct two primary types of negotiations on the project. One will be with the project customer concerning project specifications and requirements and another with the various functional managers who control the personnel resources needed for the project.
Of course, there may be other types of negotiating throughout the project – usually concerning change order work and issues that may arise. I’ve written about these before and we’re aware of these types of negotiations, though they may or may not be necessary. The negotiations be discussed in this article are almost certain to take place.
Negotiating with the Customer
Negotiations with a customer occur at a project’s outset and are done to arrive at a project’s specification. It would seem to be a straightforward task: The customer explains what is wanted, and the project manager captures it in the specification and goes ahead with the project. This is not always the case, however. Some customers may come up with only a fuzzy idea of their desired product and may need help from the project manager to discover what is possible to be produced for them. This is where negotiating enters in the process: The project manager identifies the various tradeoffs to the customer and negotiates decisions regarding these tradeoffs.
The customer may not understand project feasibility, or what can and cannot be produced—and also may have come up with time and cost expectations that are inconsistent with what experience dictates. Resolving these types of problems also requires negotiating.
Basically, the key to negotiating is to clearly identify the needs of the person with whom you are negotiating. Then, you must tell this person exactly how you propose to meet those needs, discover the constraints limiting their efforts to help you meet those needs, and discover what they would accept as an incentive for their help.
Making Informed Project Management Decisions
Posted by Brad Egeland
Making decisions is part of daily life for any manager or executive. Some decisions may result in a change of strategy in personnel policy or employee training. Other decisions may result in undertaking a project to launch a new product line. A gamble often is associated with important decisions. Newspapers frequently report the names of executives who were rewarded for “making the right decision” and those who were fired for being wrong. More than likely, those who were rewarded had weighed the pros and cons of the situation and had become thoroughly informed before deciding on the venture.
Making informed decisions is the dilemma at the heart of assessing potential project hazards. It plagues the project manager whose sponsor requests that he or she prepare an assessment of potential project hazards for the statement of work.
How does a project manager go about making informed decisions concerning potential external project hazards? By going out and talking to as many people as possible who have knowledge of every conceivable aspect of the project—and by gathering as much input from them as possible.
Armed with this information, the project manager should be able to formulate key questions for the experts who have the answers. For example, if a project involves building a new atomic power plant, a critical question for a politician from the affected district would be, “Will the government become so environmentally concerned during the construction phase of the plant that they might close us down before we can complete it?” A seismologist could be asked, “What is the earthquake possibility on the land where we propose to build?”
