The Risks of Doing a Lot with a Little
Posted by Brad Egeland
In this economy we see it every day. Either a company is shaving workers off their workforce and continuing to operate as if nothing has happened or their not hiring new workers to handle increases in work. Either way, this concept of doing a lot more work with fewer workers – which is what both scenarios play out to be – is dangerous and needs to be looked at in further detail.
When I first came to Las Vegas as the Corporate IT Application Development Manager for one of the largest gaming organizations in the world I was surprised by the size and composition of their IT department. Small development staff, no real project management structure in place, and a wildcat IT director who decided he needed to tell me on my first day who he wanted to fire before I had a chance to even assess the team. I know, I should have taken off right there and headed back the Midwest, but I do like challenges.
To make a long story short, I could see the imminent merger with another casino and left prior to that actually happening. And the IT director got his just desserts when most of the IT staff of the purchased organization (my former company) was let go. He liked to brag about doing more with less, but what we had was an IT department that was beleaguered, overworked, beaten down, and scared for their jobs most of the time. It wasn’t something to be proud of, yet he was. It’s not the type of organization I like to run – that’s for sure.
When you try to do too much with too little in the name of cost savings or personal glory, you often risk the following:
- A frustrated, overworked staff.
- High staff turnover.
- Adding additional risks into your project that must be identified, analyzed, and mitigated or avoided.
- Decreased costs initially followed by increased costs and decreased profitability.
- Poor or incomplete output.
- An unusable final solution.
4 Categories of Stakeholders
Posted by Elizabeth
The OGC’s Managing Successful Programmes (MSP) framework uses a categorisation process to identify all the stakeholders for a programme, and this works equally well for project management.
There are four categories of stakeholders, which provide a starting point for your to brainstorm all of the relevant parties involved. The four categories are: users, governance, influencers and providers. Let’s look at each of those in a bit more detail.
Users
These are the people who will use the products of your project or programme. They are the beneficiaries of the outputs. For example, these could be customers or another internal department. In the case of delivering a new software package for your Sales team, the users would be the Sales team.
Governance
These are people or groups of people who have an interest in how things are managed on the project or programme. For example, management boards or steering groups would fall into this category. Auditors, regulators, health and safety executives would also be categorised as governance stakeholders.
Do We Want Yes Men on Our Projects?
Posted by Brad Egeland
If you’re reading this, then you likely already know the answer. You know it either because A) you know that having all ‘yes’ men on our projects would be a bad thing or B) you know from the way I start many of my articles I’m being sarcastic and you want to see what I have to say on the subject. Either way, thanks for stopping by.
Project managers need to be confident – maybe even arrogant at times. But do we know everything? We may know a lot or at least need to act like we do, but we certainly aren’t the authority on everything. If we think we are, we won’t last long because we’ll screw up a project very badly sooner or later and we’ll be gone.
So, do we want a project full of agreeable project team members? Do we want unbridled obedience? Do we want out project troops to walk right off the edge like those funny lemmings in the animated Ice Age movie? Heck no!
Conflict is good
Conflict, disagreement, correction, creative and critical feedback – they are all good things, even if we sometimes don’t want to hear them. What would the benefit of having everyone agree with us on the project team? True, decisions would be fast and easy to make. Progress would never cease. Momentum would never be lost. But if my wife had never told me that something was a bad idea or that maybe there was a better way to do that, then we’d have some pretty funky home projects completed around our house that make no sense at all. See what I mean?
Team think
Our project team of technical experts was put together for a reason. We are the project managers. We oversee the project and liaison with executive management, the customer, and many third party groups on many aspects of the project including status, issues, contracts, agreements, assumptions, and approvals. However, we rely – or we should rely, anyway – on our skilled project team resources to help us make decisions and determine best courses of action on project tasks throughout the engagement. Every task should be discussed – to some degree. Team decisions are needed throughout and to rely just on our own expertise and understanding would be the truest form of ignorance. And a direct path to project failure.
Taking a Project Team Through the Four Stages of Team Development
Posted by Brad Egeland
This article continues on Mr. Lewis’ description of the four stages of a project team’s development. This information comes primarily from his book entitled, “Fundamentals of Project Management.”
The forming stage
A newly formed team needs considerable structure, or it will not be able to get started. A leader who fails to provide such structure may be rejected by the group, which will then look for leadership from someone else. A directive style of leadership is called for in the forming stage.
During the forming stage, members also want to get to know each other and want to understand the role each member will play in the team. The leader must therefore help team members get to know each other and to understand clearly the team’s goals, roles, and responsibilities. One error that may be made by very task-oriented leaders is to tell the team to “get to work,” without helping members get to know each other; such leaders tend to view purely “social” activities as a waste of time. It should be obvious, however, that it is hard to see yourself as a team when you don’t know some of the “players.”
Getting the team started with a kick-off party or dinner is one way to let members get to know one another in a purely social way, with no pressure to perform actual task work. If this is not feasible, you must find some mechanism for letting people get to know one another.
The storming stage
As the group continues to develop, it enters the storming stage. Here, people are beginning to have some anxiety. They start to question the group’s goal and wonder whether they are doing what they’re supposed to be doing. The leader must use influence or persuasion to assure them that they are indeed on track. Members need a lot of psychological support, as well. They must be assured by the leader that they are valued and that they are vital to the success of the team. In other words, some stroking is needed in this stage. Usually, a selling or influence style of leadership is appropriate at the storming stage.
There is a tendency to try to skip this second stage, as we feel uncomfortable with the conflict that occurs. To sweep such conflict under the rug and pretend that it doesn’t exist is a mistake. The conflict must be managed so that it does not become destructive, but it must not be avoided. If it is, the group will keep coming back to this stage to try to resolve the conflict, and this will inhibit its progress. Better to pay now and get it over with.
The Stages of Project Team Development
Posted by Brad Egeland
I caught the following information while reading a book from 1995 by James Lewis. The book is entitled, “Fundamentals of Project Management.” In this section Mr. Lewis describes one model of team development that is comprised of four general formation stages that teams go through on projects: forming, storming, norming, and performing. Below, each stage is described and some detail by Mr. Lewis. I realize that this text is at least 15 years old, but it does seem interesting and relevant still. I’d also like to hear your thoughts and feedback on this topic.
The four stages
There are a number of models that describe the stages through which teams or groups pass on the way to maturity. One of the more popular ones has self-explanatory titles for the stages: forming, storming, norming, and performing.
Forming stage
In the forming stage, people are concerned with how they will fit in, who calls the shots and makes decisions, and so on. During this stage they look to the leader (or someone else) to give them some structure—that is, to give them a sense of direction and to help them get started. Failure of the leader to do this may result in losing the team to some member who exercises what we call informal leadership.
Storming stage
In the storming stage, people begin to question their goals. Are they on the right track? Is the leader really leading them? They sometimes play shoot-the-leader during this stage. The storming stage is frustrating for most people.
