What I've Learned in 15+ years of Project Management

In a world where new project management tools pop up daily, people download apps to detach from their obsessive mobile consumption and unnecessarily ever-growing to-do lists dominate our lives; it’s no wonder “it’s complicated” is our answer to even some of the most trivial questions in life.

Project management is, unfortunately, no exception.

But in all of my years of project management experience, one fundamental theme has dominated the industry: we’re overcomplicating project management.

Despite most people’s opinion, most projects can be handled in a straightforward, easy-to-use and easy-to-learn method.

Project management does not have to be, nor should it be, hard.

Yet, we live in a society that likes to take the simplest projects and make them into a repainting of The Sistine Chapel.

The platform that cost $60,000

My journey into project management happened by chance.

I was working as an IT guy in a New Jersey recruiting firm. At the time, we were using a ridiculously expensive and outdated software application that allowed us to search for applicants through the platform.

And it was costing us $60,000 a year.

As a business owner, that’s outrageous. So I pitched an idea: let’s bring it in-house and build it ourselves!

Despite me having limited experience with software development or project management, the agency liked the plan enough to give me a budget and figure it out.

After sourcing my team, researching the best processes, and compiling all the resources, we built our own in-house software that enabled us to perform complex search queries across applicants for job placement.

We launched the application successfully, saved the company money, and delved into the world of project management.

The rest is history.

Within a five year period, I went from a Project Manager to a Senior Project Manager to eventually, Director of Project Management — leading an expanding team of project managers.

As my career progressed, I realized that continued learning and adjusting is one of the critical factors of effective project management.

As I grew into my new role as a VP of Technology, I was introduced to different methodologies and over time, began to master them.

One thing, however, remained certain: the majority of project management methodologies are often too complicated for what the team truly needs.

(And actually, this laid the foundation for what we, at Rindle, believe is the most optimal way of project management.)

The agency I was at used the Waterfall methodology, which was new to me at the time.

This is also where I met my co-founder, Tom. 😉

Not all project methodologies, however, are perfect. It’s impossible to hide the pain points of working in Waterfall.

You do all of this upfront work and not even get the job done.

You stress and sweat over every painstaking detail and plan all of your requirements and sprints upfront.

All of this overhead and effort, and sometimes the end result is so ridiculously far from what your team originally planned, that it’s not even recognizable as a deliverable.

That said, moving to Agile was a no-brainer.

With Agile being the growing hype in the industry, my small team of myself, Tom (co-founder of Rindle) and a few other guys decided to explore it further.

The Evolution: From Waterfall to Scrum to Kanban to Scrumban

When we first began, we planned our projects similar to that of Waterfall but operated our workflow on a sprint basis.

We realized there were times we would spend two weeks alone creating a spec and all the wireframes and never end up getting any of the work done.

By implementing user stories to plan out our projects, we could get a sprint flow actually flowing.

Over time, we went from a strictly structured methodology of planning (Waterfall), into a lean and Agile method with Scrum, and finally blossomed into a Kanban method that included some aspects of Scrum (aka Scrumban).

We, uh, never looked back.

The primary reasons were obvious:

• it’s the simplest,
• it’s the most visual,
• it’s the easiest to understand concerning the process,
• it takes the least amount of time, and
• it’s an ongoing, iterative methodology that’s easily adjustable

The best process was looking at our pain points and feeling out what was working with the ultimate goal of getting to the actual work faster - which of these methodologies we could borrow from instead of investing entirely.

When it comes to project management methodologies, there are a lot of options and many factors to think through:

• Education: do you have to train your bosses and team
• Buy-in from the team: it’s not a solo mission, they have to be on board
• Training: time, energy, cost
• Adoption: how likely is your organization to implement and utilize the process moving forward

What a lot of project managers fail to realize is this: the higher the complexities, the higher the failure rate.

Why Waterfall and Agile Alone Failed

In looking back at my 15 years of project management, and now being one of the founders of Rindle, I’ve realized why our previous attempts at project management failed.

The “Aha” moment, so to speak.

There is a tremendous amount of upfront work with Waterfall and most other project management methodologies.

Not just the upfront work with the client or internal customer, but then also the upfront work with documenting it all, creating the wireframes, waiting for approval and then finally creating all the tasks and subtasks in the project management tool and assigning them out.

Hours upon hours upon hours of unnecessary upfront work before we even got started to doing any work.

1. Complex Methodologies Are Too Strict

Whether you’re a high-growth startup, a fledgling agency, or a sizeable structured enterprise, the ability to be flexible and manage adjustments accordingly is imperative for growth.

When something is not working, it’s pretty standard for project managers to either fill in whatever that hole may be or reach out to experts who have experience in navigating a solution.

The first thing people do when it comes to managing projects is whatever seems “natural” to them — whether that’s spreadsheets, post-its, pen and paper, a combination or whatever other make-shift systems they created.

When they grow, and the team expands, they realize their method is not conducive to growth and are pressured to quickly get organized.

So then what’s the second thing they do?

They start conducting research on specific methodologies.

But when they find specific methodologies, not only are they somewhat complicated, PM’s, (especially novice PM’s), feel pressured to adhere to the structure.

For instance, those who adopt and are fans of scrum feel they absolutely must have 15-minute standups and user stories on Monday, and anything that’s not in line with it is no longer considered Scrum.

But there’s nothing wrong with forging your own path.

That’s what we did.

Instead of going down the rigid route, we opted for starting very simple, and adjusting the process if and when it was needed.

That’s also why we’re big fans of kanban.

There’s isn’t anything you can actually break with kanban.

Even if you do something “wrong” like accidentally move a card prematurely, you simply move the card back. The earth is still turning and the sky has not fallen.

But if you do something wrong in scrum, all hell breaks loose.

The thing is, everyone is different. No one works the same or has the same preferences.

Kanban offers a lot of flexibility to tailor not only your overall teams' choices but also those on an individual level as well.

And that goes into the next important realization we had.

2. Don’t Shoehorn Your Team

Don’t force yourself to work around a methodology; the methodology should work for you.

If you’re starting out as a project manager, there are a lot of unknowns, and when you've tasked a team and responsibilities, even after you decide what you think is best for the team as a whole, the challenge is ensuring everyone is on board.

You are only a part of the team.

The entire project management process is a TEAM process, and a TEAM exercise in building out your workflow.

It may not seem like it, but you’re not the boss of your team. Usually, every member of the team falls on the same level - graphic designers, contractors, developers, project managers, etc.

Although you are held responsible for project completion, it doesn’t authorize you as the boss; it just means you’re the leader.

And to lead, you need respect.

While managing a website project, I spent an entire Saturday sitting in a conference room with my mobile developer.

I didn’t know code and technically couldn’t help him, but I sat there with him.

Because as a project manager, it’s my deadline he’s meeting.

What was I going to do, party while he worked to meet my deadline?

Part of respecting your team includes listening to them and being flexible enough to adjust the way you guys work, whether it’s in an existing methodology, your methodology, or a hybrid.

Adapting to what your team needs to be as productive as possible is what all teams need to be doing.

Teamwork makes the dream work.

Nothing operates in a silo, and the end goal requires involvement from all team members, which as mentioned already, have different internal processes and preferences of their own.

Whatever it is that needs to get everyone as productive as possible is what a project manager has to figure out.

Sure, it may mean adhering to strict methodologies.

Or saying “screw it” and creating your own system.

3. Don’t Over Complicate The Uncomplicated

I remember one moment specifically when I was designing flowcharts, and I took it a few levels too far.

I was so concerned about every little step. I took what was a high-level milestone or team goal and broke it down into such granular levels that made hand-off impossible.

Anybody reading it felt like they were deciphering morse code.

As a project manager, it’s very easy to fall down this rabbit hole. You get so preoccupied with controlling every aspect of the process to get predictable results that you forget to take a step back to ensure the overall process you created actually makes sense.

Similar to building software or products (or really anything), in the end, if people can’t use it, it's worthless.