Changes in professions arise from a culmination of many factors, including advances in technology, responses to changing markets and the wider economic environment, alterations in demographic trends, and customer-driven demand, to name just a few. As well as industry-driven advancements, major shifts in the global economy and global events can have a profound, structural effect on a multitude of professions. Major global changes bring about a realization that “We cannot continue to do what we have always done.”
The full impact of the global financial crisis that began in 2008 on all aspects of the economy may take years, or even decades to fully understand. It is arguably true that the crisis has “left its mark” on attitudes towards the project management profession (as it has on many other professions). Some changes have been challenging at an individual level, such as the struggle for many to maintain gainful employment. Other changes have spurred positive adjustments to the way the profession operates, such as fostering a drive for advanced project management processes and a general realization of the importance of project management to controlling outcomes with scarce resources. In this article, we review what some of the post 2008 changes on the project management profession have been.
Project Portfolio Management is a set of business practices that brings the world of projects into tight integration with other business operations. PPM brings projects into harmony with the strategies, resources and executive oversight of the enterprise. PPM provides the structure and processes for project portfolio governance.
I could leave it right there and you’d scratch your head and ask, “What does he mean?” Or you can drop everything and pick up my 500-page book for a complete dissertation. How about a compromise – a slightly expanded explanation for now with additional segments to follow?
It’s been about a decade since PPM emerged on the project scene and, thankfully, the business world is rapidly embracing this immensely valuable management concept. Still, many project and business managers grapple with understanding where project management (PM) and PPM differ and why these are two distinct (although closely aligned) business practices.
Agile development is not right for all software professionals. If you are bringing Agile into a siloed company accustomed to plan-driven methods, expect that 10% to 15% of the people will not fit.
In my experience, individuals might not fit with their newly Agile team for one or more of these reasons:
- They strongly prefer to work alone, not as team members.
- They would rather develop their specialties than shoulder miscellaneous team activities.
- They prefer to implement other people’s plans and designs and don’t want to make any high-impact decisions.
- They feel that the Agile methodology sets them up for failure because it doesn’t mandate the detailed planning and up-front design they associate with responsible development practice.
- They are willing to go along with the Agile methodology but feel that their particular team is not up to the job, which will reflect badly on them.
Some of these folks express their displeasure quietly, doing their best to mitigate the risks they perceive. They work hard, intent on demonstrating their own performance according to pre-Agile criteria. Others resist openly, advocating a return to the trusted old ways. (Some might even act up, like the senior developer in section 7.4 who exclaimed that his team was stupid.) Some attempt to influence their managers to modify the team’s process. A small percentage — sensing the company’s new direction — may even quit.
When I ask project managers what a baseline is and why it’s important, they tell me that it is an approved starting point against which project performance is measured.
They are right, of course. But when I ask them if they use baselines, as often as not, I find that baselining is a fundamental project management practice that is neglected by many project managers and organizations.
Lack of good project discipline or good tools probably explains why many projects don’t get baselined. Understanding project performance and providing input into lessons learned are two obvious reasons for utilizing baselines.
One perspective about baselines, however, sheds light both on why it is often not done and why it should be.
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?