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
Getting the Most from Your Project Staff
Part 3 of a 3 Part Series
As a Project Manager you are tasked with getting work done through others. It may seem simple, after all these individuals are assigned to the project team and just need to do their job. But this is not reality.
What is reality is that project resources are often assigned work beyond your project and may even be involved in other projects. It is typical in the popular matrix project organization that team members do not report directly to the project manager, but rather a functional manager. This makes it even more important that the project manager have the skills to get work accomplished through others. Even the most experienced project managers continually report this as one of their top challenges.
Having provided a high-level comparison of waterfall and agile methodologies (or frameworks) in my previous article, I will now begin to analyze core areas where misconceptions arise and create problems in an environment that has been declared agile.
A failed conversion from waterfall to agile
The term “requirements” means many things to many people, and I’ve often found that even in a waterfall environment there can be confusion. I once worked in a company that had a robust business development team whose job was to analyze trends, get ahead of the industry direction, and discover new business opportunities. This team flew around the country to meet with current customers and prospects alike, talking to customers about their needs, frustrations, and visions, and then capturing them in a series of business documents such as a business cases, RFPs, and SOWs before the project was approved and they were converted by the PMO into project documentation.