by Cyndee Miller
Ahhh, late December—my time for curling up with some holiday bonbons, a nice bourbon and obsessively reading every year-end recap article, deep analysis, listicle and infographic out there. There’s loads of stuff on music, politics, books, technology, business and just, well, 2016 life in general. (The Economist even has a country of the year. Spoiler alert: It’s Colombia.)
But there’s not a whole lot of ink devoted to what went down in project management over the past year. So consider this a not-so-super-scientific look at the year that was in Project Management Land.
But on a grand scale, things were looking pretty good. The global economy continued to regain its footing (although not quite everywhere.) And project, program and portfolio managers remained in high demand across sectors and around the world. With good reason, they’re getting stuff done even amidst mind-boggling change.
No shocker here, much of that change revolved around tech, with industries like aviation and healthcare going in for major upgrades and overhauls. The Internet of Things entered the buzzword lexicon a few years back, but in 2016 we started to see what it might mean for project pros in everything from mobile to the once-staid auto industry. And as more and more devices get connected, project managers entered the front lines of the battle against cybersecurity threats. Then there are the drones, coming soon to a project site near you.
Even in such a tech-drenched year, there is no doubt that it still comes down to people. Robots will not take over the profession any time soon. For one thing, their leadership skills are just not where they need to be. Plus, they stink at managing teams.
2016 was a powerful reminder that project, program and portfolio managers are at heart change agents. Sitting at the intersection of strategy and the status quo, they’re the ones who figure out how to make change happen—and stick. And process-fueled technical knowledge alone isn’t enough. Strategic leadership skills are a must-have—and that message came through again and again and again.
Strategy is all about the pursuit of advantage—which means achieving the right goals at the right time. There’s a reason PMI’s Thought Leadership Series and Pulse of the Profession In-Depth reports focused on benefits realization. In 2016, it wasn’t just knowing how to deliver the goods, but why the goods matter.
Those are my highlights. What’s your big takeaway from the year? Is the great debate over agile approaches actually still a debate 15 years after the manifesto was published? How are PMOs faring? And what happens when there’s a PMO agile smashup?
Agile, connected cars, change management, whatever—what are you thinking about as 2016 closes?
By Christian Bisson, PMP
My last post about change stuck with me, so I want to revisit the topic by focusing on organizational cultural change here. Culture change means implementing new habits, new ways of thinking, new ways of working and so much more.
It presents a major challenge.
Why? Well, it’s more than processes, tools or documents—creating an organizational culture means changing people. This is as challenging as it gets.
When you’re looking to implement a culture change, here are few items to consider:
1. It takes time.
Most people will expect cultural changes to take a max of a few weeks, which is generally unrealistic. To level set expectations, share a roadmap of your changes.
The map should include high-level milestones of what the change will entail — training, meetings, etc. Then specify the objectives so people are on the same page as to why this is being implemented.
The roadmap will ultimately show that the changes are under control. It should mitigate any concerns or problems people will imagine.
2. You’ll need support.
A culture cannot be changed by just one person. There needs to be buy-in and it must be obvious.
I once had to implement daily Scrums with about 15 people, all of whom were accustomed to daily Scrums being long, painful meetings.
Changing that perception to one where meetings would last less than 10 minutes, where people would be on time, stand up and commit to the work they would aim to accomplish, was a challenge. I started by seeking out the colleagues in the group who were already on board with the change.
These early adopters helped me push others to stand up, be on time and ultimately helped keep things rolling when people went on tangents or brought up items out of turn. They were the first to jump in and “commit” to tasks rather than just saying whatever to get the meeting over with. It created a snowball effect, and we soon had efficient 10-minute meetings in place.
It’s a small example of a culture change, but it shows that having buy-in made all the difference.
3. Seek feedback.
All team members react different during a culture change. Some will let frustration accumulate and burst when it’s too much, others might complain as time goes, others will be constructive, others will never share, etc.
You want to take control over that by welcoming feedback, as often as you can, from as many people you can. Obviously, don’t talk to everyone everyday. Use your judgment — for example, you might want to talk to those colleagues impacted the most every week, while speaking to others only monthly.
While more time-consuming, gathering feedback from people is better done one on one. It gives you a chance to connect with the individual. If you speak in large groups, the majority of people will remain quiet while others take over.
How have you tried to implement changes to your organizational culture? Share your stories and your tips!
by Roger Chou
When the Bureau of Standards, Metrology and Inspection in Taiwan's Ministry of Economic Affairs decided to adopt ISO 21500 as the Chinese National Standard (CNS) for project management, they turned to a virtual team of volunteers to review and implement the standard.
After being asked to head this committee, my first step was to make Scrum practices the method for doing the work. From there I worked to:
1) Centralize collaboration.
Since our committee of more than 30 volunteers (broken into three teams) worked virtually, we needed a tool to communicate and collect information. We relied on the LINE communication app and Google Docs.
2) Create a product backlog.
This backlog was a key reference tool for the committee. It included key stakeholder interviews and user stories that established the needs of CNS.
For example, one story said:
“As the Committee for Chinese National Standards on project management, I want the second version revised to cover our terminology standards so that it won’t waste our time in reviewing the work.”
3) Plan how to perform the work.
I instructed the individual team leaders to let their team members break the user stories into tasks to help them feel ownership of the work and create more accurate tasks.
The tasks were set up to be no more than one day’s work over four sprints (4 weeks total), allowing us to keep the momentum going.
4) Meet regularly with team leads.
This helped ensure teams were working effectively with each other. In this meeting the individual team leads were asked the following questions:
- What has my team finished since the last meeting?
- What will my team do before the next meeting?
- Are there any impediments in my team's way?
- Are there any impediments caused by my team for other teams?
5) Hold sprint reviews.
Throughout the length of the project we held weekly sprint reviews with external stakeholders.
This step not only ensured the volunteers worked to a high standard, but since this work was reviewed collectively, it served as a reminder of the commitments the teams had made to each other — be that deadlines or level or work.
When the final project was completed, it was submitted for review with a panel of industry, government and academic leaders. Our final step was to create the final user story:
“As the product owner of the project, I want to collect each volunteer’s reflection and thoughts, of about 100 words, to make the closure report, So that I may let those new to project management know how to run virtual teams with Scrum and I want to publish these stories.”
Work on this project was constant, sometimes requiring long nights of work. But it was always as a labor of love.
How do you streamline projects for virtual teams? What would you have done differently when managing a large volunteer effort like this one?
By Kevin Korterud
As project delivery methods have evolved, so has project leadership. Hybrid approaches have emerged: Traditional waterfall project and program managers are now faced with the prospect of having a portion of their work use iterative agile approaches. Agile Scrum Masters and product managers executing rapid iterations of new products now have to contend with budgets, financial forecasts, release schedules and business case benefits, as well as with aligning implementation of products with other projects across the enterprise.
With this as a backdrop, a frequent question that comes up from my colleagues is whether an industry needs a project manager who knows agile, or agile leads who are competent in more traditional project management practices. In today’s complex world of delivery, we urgently need both.
1. Project Managers Need to Understand Agile
It’s inevitable that a project manager will at some point oversee an agile delivery process. So it’s important that project managers start their journey to competency as soon as possible. This journey can begin with training in agile methods as well as shadowing an agile lead to see how the iterative process works.
As the journey continues, project managers will start to immerse themselves in advanced areas such as agile metrics, alignment of agile to testing and release processes as well as the people factors. A project manager will soon see what sort of projects can best be delivered through agile vs. waterfall methods, as well as the linkages to enterprise functions required regardless of delivery approach.
2. Agile Leads Need to Understand Project Management
Agile leads typically have experience with iterative methods used to quickly shape and deliver solutions. In addition, they typically have a strong business analysis background that comes into play when defining user stories.
In the past, these skills alone were sufficient for agile delivery efforts.
With the complexities of contemporary delivery, however, many agile leads now encounter similar expectations when it to comes to schedule, budget, product quality and business case realization as their waterfall counterparts.
These expectations compel agile leads to gain skills in traditional project management areas such as estimation, forecasting, resource management, technical requirements as well as testing and implementation practices. Acquiring these skills will enable agile leads to deliver higher-quality products in a more timely and efficient manner.
3. Everyone Needs Enterprise Function Support
As hybrid project delivery approaches become more common, the considerations for aligning delivery activities to produce the most value to an organization become more numerous. These considerations can include (but are not limited to) the speed at which agile produces product iterations, business and technology complexities, and the increasing expectations of consumers.
All of this amplifies the importance of enterprise functions such as portfolio management, release management and resource management. These and other traditional enterprise delivery disciplines have been identified by the Scaled Agile Framework (“SAFe”) as being key to success.
It’s not so much that the SAFe framework has had a “eureka moment” around enterprise functions as new innovations. Rather, it has identified the critical need to have these functions in place and engaged for all types of delivery. Both project managers as well as agile leads can be more successful when tightly integrated with enterprise functions. Without having robust enterprise functions in place, organizations will struggle with more frequent schedule, resource, dependency, testing and implementation conflicts. And those conflicts dilute the business value of projects regardless of delivery style.
What do you think? Do organizations need agile leads with project management knowledge, or project managers with agile knowledge? I welcome thoughts regarding delivery successes and failures relative to either or both roles.
By Jen L. Skrabak, PMP, PfMP
Seven in 10 organizations have a PMO, according to PMI’s 2016 Pulse of the Profession. That’s roughly the same as what other PMI surveys have shown in recent years. Why has the prevalence of PMOs plateaued? It could be that many people still perceive PMOs as providing low value but high administrative costs while doing little to improve project delivery.
Worse, the general state of project management isn’t improving in spite of this increase in PMOs. Organizations waste US$122 million for every US$1 billion invested in projects, according to the 2016 Pulse report. That’s a 12 percent increase over the previous year.
Why the disparity between project success rates and the prevalence of PMOs? There’s a gap between the vision and reality of PMOs. Here are four reasons why people may hate PMOs—and what PMO leaders can do about it.
1. Redundancy Over Efficiency
I’ve worked in multiple Fortune 100 organizations where there were not just one, but multiple PMOs, that a critical portfolio may have to report into.
There may be functional PMOs (i.e. IT PMOs and/or business division PMOs), capital-planning PMOs, product PMOs, or enterprise PMOs, just to name a few. These multiple layers can cost the portfolio manager tremendous time and energy in trying to manage multiple PMO demands and requests.
There is value in centralizing and standardizing portfolio information and providing visibility to executives to enable decision-making. However, the next time we just start up a new PMO or implement portfolio management processes, we should ask ourselves if there are existing areas that already provide the same type of oversight and control.
2. Bureaucracy Over Execution
In many organizations, it takes a village just to get a new program or project approved. The focus is on the administrative side of things—filling out the right forms and attending the right meetings—and rarely on improving project delivery or execution. If a PMO’s primary focus is on gathering status reports for a dashboard, it loses touch with day-to-day execution.
There is a lot of complexity in organizations that portfolio managers must navigate, and the key is not to add more.
Ask yourself: Is your PMO’s focus on adherence to process and methodology, gates and deliverables? Are you generating voluminous portfolio data without succinct actionable plans that will increase project success?
3. Templates Over Talent
PMOs often focus on generating templates rather than having trained and skilled project managers that can assist in all aspects of delivery, especially enabling organizational change management. Portfolio management processes need to be sustainable and repeatable, demonstrate measurable impact and contribute to project success.
Too often, PMOs focus on the templates to try to enforce the process instead of having the right talent in place to help programs and projects be successful.
4. Tactics Over Strategy
For some organizations, there’s not as much value in tracking schedule and budget adherence as there is in developing the next innovation that will greatly advance strategy.
By definition, strategy changes in response to environment conditions, competitors, or the need to innovate. Is there agility (speed and flexibility) in your PMO processes that allow you to react rapidly? How can you inspire innovation in your portfolio rather than stifle it? Is your PMO positioned to identify the next innovation, and rapidly move it forward? Why not?
Why do people that you have worked with dislike PMOs? How can they be improved? Please share your thoughts below!