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.
August 2010 PM Survey – Where are You Now?
Posted by Brad Egeland
Given the economy, I thought now would be a good time to gauge where we are in our employment status. Some of us are employed, some not employed. Some are consultants, some want to be consultants. Some are happy where they are and some are searching frantically for a better position.
I’ll admit, I was having trouble coming up with good questions and response options for this one, but I did my best. If you have suggestions, let me know and I’ll create a part 2 to this survey.
The survey is up now and available for you to take at www.bradegeland.com. As always, it’s completely anonymous so please take the survey – the more responses we get the more meaningful the data will be for all of us.
As always, there are five questions so it won’t take you long to complete. Question #1 focuses on your current employment situation (W2, consulting, working in a non-PM role, unemployed, etc.).
Question #2 focuses on those who are actually actively looking for work now. Are you a W2 employee who is searching, a consultant looking for W2 work, unemployed and searching, or content with what you’re doing now?
Question #3 is asking what your favorite job site is. Dice, Careerbuilder, Monster, Craigslist …. something else? If you use something other than the first four, please feel free to give us details in the comments. We’ve probably all used them all at some point, but which one is your favorite or where have you found your best success so far?
Twelve Characteristics of Ineffective Teams – Part 2
Posted by Brad Egeland
In the finale of this two-part series well examine the final six team characteristics that I believe indicate that a team is performing ineffectively. My hope is that we can all gain insight from this list and work to correction these situations if we see them in our own teams. And please feel free to comment and share your own thoughts on ineffective team behavior or characteristics.
Conformity and mind protection. Insecurity permeates people for fear of being different or ostracized. People do not speak or share information unless it reinforces behavior or thoughts. If openness and creativity is not cultivated on the team, then productivity may be sacrificed in the long run.
Low tolerance for diversity. The pressure to conform is so intense that anyone different in thinking or work style is ostracized or not taken seriously. Whistle-blowers and creative types, for instance, may be viewed with suspicion. Under such circumstances no opportunity is available to capitalize on people’s strengths and address their weaknesses.
Insufficient resources. Whether it’s people, equipment, supplies, facilities, time, or money, insufficient resources make teams ineffective. The situation can also lead to conflicts, dissention, even revolts. If resources are not distributed in an objective, meaningful manner, then differences can magnify into severe conflicts. Members of the team can quickly become polarized.
Lack of management support. If team members perceive—whether justifiably or not—that management is not supportive of the project, then motivation can plummet. People will feel that the work is not valuable to the organization. When this happens, it may take an act of God – or at least executive management – to right the ship.
Twelve Characteristics of Ineffective Teams – Part 1
Posted by Brad Egeland
In Part 1 of this two-part series well examine the first six of twelve team characteristics that I believe seem to point toward ineffectiveness. By no means is this an end-all list, but it’s a decent start and will hopefully help us all see warning lights early enough on in our projects to make the necessary changes to fix the situation before it’s too late.
No processes for gaining consensus or resolving conflicts. Team conflicts and overt and covert discussions are ongoing occurrences, making cooperation difficult, even impossible. When this happens it appears that the project manager has lost all control of the team and that indeed may be the case. Getting back on track become more difficult the longer this persists.
Team members who lack commitment to the goal. No one has an emotional attachment to the goal. And without that goal focus there is no real drive for the team – no ownership of tasks and pride in successful outcomes. Soon, no one really cares.
Lack of camaraderie. The team members do not feel that they are part of a team. Instead, everyone acts in his or her own interests. This is a bad direction for a team to head as it can lead to rogue actions and behavior, dissention, conflict, and even straying from completing one’s tasks.
Lack of openness and trust. Everyone is guarded, protective of his or her own interests. Openness and truthfulness are perceived as yielding to someone, giving a competitive advantage, or exposing vulnerabilities. When this happens, idea sharing is at a minimum and that is never good if you want to be part of a successful, cohesive team on a successful project.
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.
