Don’t do projects
For decades, organisations and teams have tried to fix their problems by creating and running big projects with the hope that they will fix whatever is not working at the time: customer satisfaction, employee engagement, sales or whatever process is not working.
Usually the story goes like this: executive team identifies a problem they want to solve, a cross-functional team is assembled with some of the brightest people and minds in the organisation, we give that team and project a fancy name like ‘Phoenix’ or ‘Catalyst’ or ‘Synergy’, we set that team a timeline and a budget, and we hope they will fix the problem by the end of that agreed time and money.
History shows that is not actually what happens. Most projects run overtime and overbudget and in many cases they fail to fix what they were trying to solve in the first place. Usually, it is because we try to simplify a very complex problem like Customer Engagement and Satisfaction by giving it “one solution” that will fix everything: eg. implementing a system like Salesforce. The same thing happens with employee engagement and whatever IT provider’s platform promises to deliver everything we need to uplift and improve our employee engagement and satisfaction.
Another problem that this approach creates is that it is usually the same people in organisations that get pulled to work in not one but many projects at the same time. And this happens in addition to their “daily jobs,” creating a huge workload and potential burnout in some of the best people in organisations and teams.
On the other hand, people that come together and form part of project teams, usually report a higher level of satisfaction in terms of enjoying their work and contribution. I believe that the reason for this is because those projects, if well ran, have a clear purpose and vision, benefit from the expertise of cross-functional team members and, as I mentioned, are usually formed by the brightest people and minds in the business. In fact, many project team members dread going back to their BAU teams because they don’t get that level of satisfaction and engagement.
What is the solution then? I believe it is to focus on generating those feelings that project team members get, but without the downside of projects.
I worked for an organisation in 2012 that had no project management or projects. It was all run as “products” and with product managers. It is a very small nuance, but an important one. It implies that the work was always ongoing, with no end in mind (as projects do) and the business’ important work was structured as product lines and with product teams. These product teams were cross functional and had all the needed expertise (digital, marketing, legal, sales, etc…) to make sure that “product” was successful all the time. The product teams continued to create and add features to those products continuously and therefore enhancing the customer experience at the end. Now, you may think that only digital products can be run this way, but I believe that any “piece of work” could be structured in a similar fashion.
At Neu21, we don’t use the term projects either; we call them initiatives. And that small change in language, I believe, gives those pieces of work a more experimental and “product type” approach to the work.
We divide our work in three types of work: Everyday, Evolutions and Experiments. In fact, we thought to call our framework E3’s for a while and trademark it! Kidding.
“Everyday” is what most organisations call BAU (Business as Usual), what keeps the business going. “Evolutions” is what most organisations call Projects, and we called it evolutions on purpose to create that ongoing and never-ending feeling to it. And Experiments is what most organisations call innovation, things we have not tested and that we are going to play with it.
Every quarter we decide as a team what Evolutions and Experiments we want to tackle. How many? Well depending how busy we are with our “Everyday” work. Different teams then get formed every quarter for those Initiatives depending on the expertise needed and availability. Do any of those initiative run for longer than one quarter. Of course, but by resetting every quarter it gives us the opportunity to either kill, pause, pivot or continue with the initiative as it was.
