Without a doubt, how well we handle change plays a large role in determining our success in life. The same is true for companies—those that are more agile at managing change in their organizations can drive better performance.
Most of us know this intuitively—social media forums in project management, IT leadership, and business analysis continuously buzz about how leaders can amp up business results through change. Whether designing and implementing new solutions, improving business processes, stretching business unit targets, or managing people, we all play a role in helping our companies innovate and grow. In fact, a recent survey of nearly 700 business professionals revealed that 73% agree leading change is an important part of their job.
Many years ago I worked in a Project Management Office at a large financial institution. Once a week I prepared a project status report for executive management and the PMO director. I would calculate how we were tracking to budget, list any major issues or risks, and summarize overall status.
I was also told to mark the project as red, yellow, or green – using the following definitions:
Most Agile experts recommend dedicating people full-time to their Agile team. Developers, testers, and other professionals should only deal with items in their team’s work stream — the backlog. This minimizes the cost of switching between unrelated activities and enables the team members to concentrate on their work.
Management usually frowns on this advice, for two reasons:
- They want to maximize people’s output. If someone is only needed 80% of the time on one project, what happens with the rest of his time?
- The workload usually includes more than net new development. It also includes production support, some training, fixing older versions, roadmap planning, or merely smaller one-off projects. These activities are often managed separately and, to staff them, individuals are “sliced and diced.”
Many individual contributors also embrace this thinking. They consider it reasonable that they be 60% on project A, 25% on project B, and 15% on project C.
To almost quote Shakespeare’s “Hamlet” – to document or not to document, that is a risk question. This article is a follow-up to the BATimes publication, “Verifying Requirements Documentation.” As author of the article, I took special note of a readers comment on providing organizations a continuous process improvement model on composing a business requirements document (BRD). The comment was:
“... I too found some things worth cutting and pasting into some training or checklist material. The post script was prophetic - the environment for BRD seems to be getting squeezed by those who find the whole process "too cumbersome" and not (lowercase) "agile enough". I know of lots of orgs whose risk tolerance is so high that they could never see the ROI in it. I Think much of the great material here could be better digested by some organizations if one applied it as part of Continuous Process Improvement. As you find cause to question your BRD effectiveness, compare your process for creating brd documents to this model. While few organizations are willing to invest in all of this effort up front (and it can be appear to be oppressive), laying this out as the gold standard sets the bar for where you can go. When flaws are found or systems don't meet expectations, the project closure efforts should certainly involve looking at the shortcomings, comparing to this list and considering what additional pieces should be included next time to avoid the flaws, increase acceptance, or implement a solution that's more relevant to the customer....” #Tony 2012-01-25 22:20
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.