Decision-making errors exist within all levels of organizations. Some common examples include:
Focusing on the symptoms instead of the problem
- Having no clear picture of the desired outcome
- Becoming fixated on only one option
- Making decisions that do not align with the overall goals of the organization
- Missing opportunities to set decision criteria
- Failing to evaluate enacted decisions
It is important to recognize and accept (without blame or shame) that mistakes occur. Then it is time get over it, move on and apply a process that will enable successful decision making.
One defining characteristic of any team is their shared purpose. I always ask about it when I meet a new team. The answer is usually beige, something like, “We do the social media component.” Stronger teams have an identity, a vivid purpose, or an inspiring vision. Such teams ask themselves, “What must we do together that is larger than any of us, requires all of us, and for which none of us can claim individual victory until it is done?” [i] In some cases, a team will reflect their identity in a name. [ii]
Basic affinity between the members is necessary for them to want to be with each other. Some common background and shared interests are helpful, although shared values are much more powerful. Imagine you and I are on a team writing medical software. You were attracted to your job because it improves people’s lives, whereas I joined for the outstanding pay, which allows me new luxuries. We are both motivated and willing to work together, but would you care to work with me? Would you go the extra mile on my behalf, or have my back, when you know I’m really just in it for the money?
An approach to defining and implementing your collaboration model
How adept an organization is at collaboration can be a competitive advantage or, alternatively, a source of significant risk. The general makeup of project teams has been shifting to a more diverse, virtual makeup as organizations spread out geographically and increasingly work with multiple stakeholders on projects. Project management approaches that do not take into account increased communication and collaboration needs created challenges for which organizations are ill prepared. While the market is flooded with tools that claim they can improve collaboration, purchasing a new tool and weaving it into a company's infrastructure is often not within the available budget. Moreover, a new tool may not be the only answer or even the recommended first step towards improved collaboration.
We suggest that the most economic and effective approach to improved collaboration is to understand your project team’s environment and communication needs by taking the time to define a collaboration model. The path to designing a collaboration model takes diligence in identifying and evaluating your organization's project, people, processes and existing technology in order to determine the optimal collaboration processes and tools to support the organization.
Thomas Edison once said, “Hell, there are no rules here – we’re trying to accomplish something.”
Rules, rules, rules. They constrain us, can make us feel patronized, and conflict with our git ‘er done ethos. But without them…sometimes we’re a mess!
I certainly felt like one earlier this summer while watching our son play his first lacrosse game. There we were on the sidelines trying to figure out what the heck this game is all about. Most of us watching were veteran hockey parents entirely familiar how things work in that game. But this was the first lacrosse game most of us had ever seen and the whole experience was more than a little unnerving.
The Project Management Body of Knowledge (PMBOK) defines a project charter as a document that formally authorizes a project.
The project charter is not created by the Project Manager. Instead, it is issued by the sponsor to empower the Project Manager with the authority to begin the project and obtain resources for project activities. The project charter should include at a minimum the following:
- business need for the project which links the project to the organization's overall strategy
- stakeholders and their initial requirements
- objectives or quantifiable criteria that must be met for the project to be considered successful
- definition of what is in scope (at least at a high level), as well as out of scope for the project
- constraints and assumptions
Hiring a project manager is a real challenge. A good project manager has to be capable of combining interpersonal skills with the technical aspects of project management. Unless you either personally know the person or have a personal recommendation from someone you trust who knows exactly what you are looking for and what the candidate has to offer, you won’t know if you have the right person until after they have started work—although you might quickly learn that you have the wrong person if things start to turn sour quickly.
Hiring starts with knowing what you need and why you need it, and then the search for potential candidates begins. As someone who has seen job descriptions for many project management positions, who has been a project manager, has trained project managers, and has hired (and fired) project managers, I’ve often seen a lack of clarity in what people’s expectations are regarding project managers, which results in an ineffectively written job description. You can save yourself time as a hiring team, and the time of candidates and recruiters, while improving your odds of getting appropriate candidates by making sure that you are clear on what your needs are and articulating them in a well-constructed job description.
Doubtlessly, many of us have experienced project(s) that seem to have been the direct opposite of the prescribed organizational and/or well-heeded PMBoK methodology we have been duly trained in. When describing the project environment of a relatively recent experience (aka project assignment) I was involved in, it would be more accurate to suggest the project footings were as steady as typing on a tablet while riding a unicycle. In many respects, designing/architecting (a sort of planning) gave way immediately to execution, and the operational steady state was an interesting afterthought. The focus of the article (setting aside the issues of management decision making, project happenstance, and project processes) is to underscore the great lesson learned of how brilliantly people can excel and collaborate in an extraordinary fashion in the absence of commonly accepted documentation and governance practices. The rarity of this project team interaction points out, for all its process faults, project instability can lead to successful projects.
Communication is widely recognized as being among the most critical responsibilities of any program, project or portfolio manager, given prominent standing by the Project Management Institute in A Guide to the Project Management Body Of Knowledge® (PMBOK® Guide). However, even with extensive guidance in this critical area, there is less clarity regarding how to devise and implement an effective project communications strategy. This article provides fundamental recommendations proven critical to success at any level of complexity, whether a small project, a large program including multiple interrelated projects, or a troubled project in need of recovery. This guidance is also beneficial for continuous assessment across complex project portfolios.
A core communication goal is to enable timely decision-making. Specifically, channels of communication (that is, the flow of communications through the web of stakeholders) should mirror as closely as possible the channels of optimized decision-making. This may appear trivial as many recall the game of Telephone where a message evolves in passing from one person to another until finally returning back to the first person. But failure to apply this rule is a leading cause of many project and program problems. This is most evident at the project sponsor and steering committee levels. Consider the consequences of playing Telephone with critical status and decisions on a large-scale program.
What is quality? There are many different definitions of quality thus the term may cause confusion for project managers.
For the Project Management Professional (PMP) exam, you need to understand that quality is defined as conformance to requirements. The Project Management Body of Knowledge (PMBOK) defines quality as "the degree to which a set of inherent characteristics fulfill requirements."
Quality management involves ensuring the project meets defined needs. The PMBOK states that quality management "ensures that the project will satisfy the needs for which it was undertaken."
With quality defined in these terms, you can begin to appreciate and more readily understand that clearly stated requirements are essential. Requirements should define project scope, describe what is considered to be acceptable quality, and indicate how quality will be measured. This is critical to understand for the exam.
Many of the questions on the PMI Professional Project Management (PMP) exam will be situational and will deal with handling conflict because this is such an important and challenging topic.
Most of the time, conflicts on projects occur over the following issues:
- Technical issues
- Personality conflict