This introduction to project management explores what project management means in a modern business environment. This article is not about running major construction projects. Nor is it about delivering major infrastructure projects, such as HS2 or Crossrail. It is not about planning to put humans on Mars.

No, this is about the type of project management that happens inside modern businesses. We will look at a simple case study that explains what project management looks and feels like and how it makes a real difference to how organizations operate.

Our story looks at the challenges of delivering inside a growing online store called cult-culture.com. The organization may not actually exist, but the story of project management plays out in organizations of all shapes and sizes, every hour of every day, everywhere around the world.

Delivering at cult-culture.com

Cult-Culture.com was the brainchild of Steve and Aaron. While at University, they were part of a community that enjoyed role-play games involving space marines, knights, and warlords. They discovered they could make a living selling painted figurines to others at their University. Over time, they added online sales, expanding their business rapidly.

Business was good, and the organization evolved from something they operated from student digs to an organization that employed people with titles such as ‘marketing manager’ and ‘head of logistics and warehouse.’ In addition, they had a contact center committed to delivering their famously high standard of customer care and an HR manager who championed fair remuneration for the hard work expected of everyone who worked there. In IT, there was a team that managed the internal technology, but also a small team of software developers who maintained the cult-culture.com website and worked hard to respond to changing technologies and user needs.

Everyone knew how the organization worked and which department did what. Bar the occasional hiccup; things ran very smoothly.

Problems at Cult-Culture

But there was a problem. Sales had stagnated over the past 18 months, and the board decided to expand their product line into clothing. This seemed like a simple step: they had a loyal fan base and an online store-cart system. All they had to do was add t-shirts and hoodies to the mix. The marketing team was excited. They got to work immediately to discover what products they believed would sell and to pull together a plan for the marketing launch.

But outside of marketing, there was less enthusiasm. Teams saw challenges and couldn’t see how the business would make the change work. For example, customer care lacked information to share with customers. The logistics team had no idea how the additional stock would be managed. And the web developers had a long list of reasons why the change couldn’t work. Their biggest issue was that they had optimized the website to sell figurines rather than clothing in various sizes.

Frustration at board level

The board was frustrated. They believed in the idea, but it was quickly becoming apparent that the work needed to turn the concept into reality was too big for any single department to deliver. The marketing team got frustrated at the lack of progress in other teams. At the same time, elsewhere in the business, people simply carried on doing what they had always done, the way they had always done it, because the new idea seemed doomed to failure and wasn’t worth putting the effort in. Finally, at the regular executive board meeting, the CIO suggested a way forward:

What we have here is a project that cuts across each of our teams. We should hire someone with the specialist skills to define specifically what needs to be done. Then we can get them to plan it and coordinate delivery.

The COO agreed, adding:

We’ll need someone who is a good communicator too; someone who can make sure everyone knows what is happening every step of the way. I don’t want any surprises.

The deal was done. They agreed to hire a project manager. As the CIO knew the most about project management, she took responsibility for recruiting the PM and getting the project up and running.

Hiring a Project Manager

Sarah, the CIO, sat staring at a page. She’d worked with Project Managers before, but this was the first time she’d hired one for her team. So she did what any good CIO does when they get stuck: turned to Google. A quick Google search threw up several suggested project manager profiles. Sarah spent several hours reviewing them and selecting elements she believed were a good fit for what cult-culture.com was crying out for. When she was done, she looked at her list of attributes:

• Excellent organizational skills to plan the use of people and resources to meet deadlines;
• Strong interpersonal skills to inspire, motivate and lead a team;
• Good communication skills and negotiation skills (good at managing expectations);
• Ability to hit the ground running and make good decisions under pressure;
• Good at estimating and forecasting progress (predictability);
• Experience in delivering a similar project in a similar organization could be an advantage;
• Evidence of a commitment to learning relevant skills (Project Management Certification and proof of continuous personal development).

Sarah smiled. If she could find the right person to join the team, she’d be well on her way to making the project a success.

Introduction to Project Management

Sarah felt she had struck gold hiring Jez. As well as being PMP certified, he had previously worked in small online companies. And best of all, he was a big Warhammer fan. He introduced a simple Business Project Management structure with four sections: Initiating, Planning, Executing and Control, and Closing.

Starting with Project Initiation

Jez started with Project Initiation. There was some initial push-back from the marketing team, who felt that the project was already well underway, and this felt like a backward step. But with Jez’s calm demeanor and Sarah’s full backing (she was now, in Jez’s parlance, his ‘Project Sponsor’), he managed to get all of the key players into one room. He introduced something called BOSCARD, a mnemonic that, despite being oddly hard to remember, helped the team collaboratively agree on Terms of Reference for the project. The workshop was not without its hiccoughs. At one point, Jez asked whether there was a business case for the project. This question simultaneously earned him appreciative looks from the financial controller and daggers from everyone else. “We don’t need a business case; we already know it is the right thing to do,” came their response. Jez couldn’t help but think they were trying to initiate some kind of Jedi mind trick on him. It wasn’t going to work.

Jez explained. How will you know the project has succeeded if you don’t have a business case? “As the project manager, I will be able to tell you how much you have spent and whether you have delivered everything you planned to deliver, but 6-12 months after the project is done, you’ll want to assess the success of the project critically. And at that point, it won’t be about milestones and deliverables; it will be about whether we achieved what were shooting for upfront.”. Everyone agreed that he was right, and further sessions were hastily arranged.

Despite being hard work to produce, the business case and the terms of reference proved invaluable. Jez used them to introduce people to WHY the project existed and WHAT benefits it was setting out to achieve. Jez took the time to share this news with everyone connected to the project (people he referred to as project stakeholders).

Project Planning

Planning was where things got challenging. Despite everyone insisting the project was simple, it felt to Jez that everyone was only seeing a small part of the bigger picture. He explained this to them using the analogy of a group of blind men coming across an elephant for the first time (link in case you are unfamiliar with it: https://en.wikipedia.org/wiki/Blind_men_and_an_elephant). He organized a planning session where everyone could articulate the work that would need to be done on the project and build what Jez called a Work Breakdown Structure with post-it notes on the office wall. When it was done, it looked like an organization chart but detailed everything that would need to happen, from finance and warehouse modifications to website changes and changes to the staff bonus targets.

People Deliver Projects

For the first time, the whole team could see the entirety of the task ahead of them. There was quiet in the room for a moment before murmurings rose about how much work there was, how it was ‘too much,’ and how they ‘couldn’t possibly get it all done.

Jez looked unfazed. He’d seen this before. “Have you heard of the Kübler-Ross model?” he asked. Next, he explained the typical cycle of emotional responses during a change project, from initial excitement and energy to disillusionment, finally, improved happiness and success. “This is exactly what is happening now and what will happen to your teams during this project.” Finally, he explained to the project and senior leadership team how they had an important part to play in helping the rest of the organization on the journey through frequent and relevant communication, consultation, and respect for people’s positions and beliefs. After all, he said, “No matter how many Project tools you may have, it is people who deliver projects.”

Agility to manage complexity

Given the size of the project and their lack of experience, Jez advocated an agile approach. He proposed the team would focus on iterative and incremental delivery rather than trying to deliver everything as one big project. Jez introduced the team to The Agile Manifesto and the 12 principles that underpin it. He explained that while it may take longer to deliver absolutely everything, the approach would allow them to deliver some of the projects faster while giving them more flexibility to change course along the way.

Initially, Sarah had some concerns. She’d heard stories of arguments in the software delivery community about two different approaches to delivering projects. She asked whether it was better to deliver with Waterfall or Agile. Do Both! was Jez’s response. He pointed her to an article at tcgen.com advocating a blended approach. He then explained how it was important not to get fixated on any one approach. Instead, take the best ideas from both and adapt them to the unique environment at Cult-Culture. We need to rise above the waterfall vs. agile debate, he said.

Story Mapping

There was some confusion, so Jez took the team back to the wall with a fresh set of post-it notes. “I don’t see how another Work Breakdown Structure will help,” grumbled someone. But this time, Jez introduced a concept called Story Mapping.

Using post-it notes, they quickly mapped out the end-to-end processes that needed to be created to support the change. But once this was complete, Jez encouraged the team to develop customer and user personas to represent the types of people who would be engaging with the processes. He made them pick a straightforward persona identify the smallest number of post-it notes that could be used to fulfill the needs of the person in the persona.

Delivering the first slice

It took several attempts, but after a while, the team had established that they could sell a limited run of tee-shirts (large size only) with minimal changes to systems and by using storage space in the corner of the office where the Christmas decorations were usually stored. It wasn’t groundbreaking, but everyone quickly recognized that this small, thin slice of the solution could be delivered rapidly with minimal effort. This would allow them to see whether clothing would sell and start generating some user feedback. The marketing team was excited again and started planning how they would solicit customer feedback.

Depending on the outcome from the first slice, the next iteration could focus on broadening the product line, improving the supply chain, adding sizing options and automated returns policies, or even something entirely different based on user feedback.

A New Normal

The launch of a single tee-shirt was low-key. Sales quietly went live on the cult-culture.com site on a Tuesday evening. Sarah recalled it was raining that night, but the whole team had stayed late and celebrated their first step into selling clothing. The tee shirts sold out quickly, and the marketing team gained valuable insight from customers on what they liked. Next, they launched a competition for loyal customers to design an exclusive cult-culture hoodie. Again, this sold out rapidly.

Using different management styles

Jez juggled several different styles of management. A traditional business project management approach was used with careful up-front planning for the physical changes to the warehouse to handle the new stock. He was reminded of his father’s advice from his years as a carpenter: Measure twice, cut once. With such an expensive investment, it was essential to take time to get the planning and design completely right before starting the building work.

Other parts of the project continued with an agile approach. Changes to the website could be deployed rapidly and to a small percentage of site visitors. This meant changes could be deployed faster than ever and rolled back instantly if there was a problem. While Agile is generally seen as an IT software project delivery approach, it was adopted by the marketing team for their campaigns and by HR for managing improvements to their human resources systems.

Project closure

Six months after the project started, Jez called the team to a final meeting. First, they reviewed the Business case and the Objectives they’d set themselves in the project Terms of Reference. Then, it was time to complete the project’s final phase: Closure.

With Jez at the helm, the team reflected on what had gone well and what lessons could be applied to future projects. Then they ensured all the outstanding actions were handed over to operational teams. Finally, Sarah agreed to take responsibility for reviewing the business case in a further six months to reflect on whether they had hit their sales figures. Based on the early results they were seeing, the team was confident they would be successful.

After the project

The business kept the agile teams in place even after the project closed. This is because the approach to managing work was well suited to operations as well as projects, and the team focused on continuously improving themselves while remaining flexible enough to work on whatever items of work were prioritized by the business.

Traditional project management stayed too. Jez continued to work for Sarah, and they built a strategic Project Management Office that focused on supporting strategy definition, planning, and agile and project delivery. Through what started as a reaction to stagnating sales, Cult-Culture.com had developed new ways of working and was ready to face the future.

Afterword

This scenario is not an uncommon one. Modern project managers are expected to bring a wide range of tools and techniques to the table. And they are expected to help organizations deliver faster than ever. Frequently project managers have to work across business silos to get work done, experiencing all manner of resistance and disillusionment along the way. Agile techniques are massively growing in popularity due to their ability to handle complex problems that traditional methods tend to struggle with. Good project managers will know when to deploy agile techniques and when to use traditional approaches. Excellent project managers will learn how to mash them together to maximize delivery.

And the strategic PMO? Well, they are becoming part of the project success story in many organizations. They help deliver the right things faster, whether with project managers leading projects, program managers leading programs, change managers initiating change, and agile teams blurring lines between operational and project work. Or coaches working to help people and teams be the best they can be.