Getting It Done: The Project Management Fallacy

Creating stuff isn’t easy. Whatever the project might be, starting from a blank sheet of nothing to end with a ‘thing’ is a feat to be respected. May it be; copy for advertising, building furniture, writing a script, coding for the whatever platform; it doesn’t matter, building a product, creating a business; materializing from idea to something requires time, money, and blood & tears.

I’ve been in web development professionally for seventeen plus years and in which I’ve experienced some cutthroat practices. In that time, I’ve traversed many project managers whom some think that the magic in getting an initiative complete is all about directing (or in some unfortunate cases commanding) and in part, this idea is partly true. But project logistics is an important component of understanding how pieces of a puzzle get moving. Yet, the majority of project managers I have had experience with seem to miss this ingredient. The best, manage client expectations and maneuver timelines like acrobatics. The professionals understand the vocabulary of the multi-discipline development environment and they use this knowledge like a session surgeon; It’s not just clients to manage but designers, programmers, third party contractors and even studio owners. So what’s the fallacy?

The ability to influence the outcome of a project depends on the project stage.

Too often I come across project managers using the mantra of ‘hustle’ and the idea of ‘If you’re not hustling your team, you’re losing’. And sure, why not, it’s motivating, it’s inspiring and it’s a concept we’re all familiar with (especially in the entrepreneurial space). We’re paid to make things happen and employment is in the market of labor. If you are a sole proprietor, this is true more so since the more projects in a competitive state, the more pay you get. In the advertising space, this idea is ingrained.

So again, what is this Project Management fallacy? Frankly, it’s an error in the way project principals think about time.

To start, the fallacy lies in the thinking that – the further the project gets into production, the plasticity of the outcomes remain the same. And this is just not true. We’ve all been involved with projects that seem to change objectives regardless of the development phase. I’ve witnessed projects radically alter scope within a third of a project milestone, and this was within a studio environment. Is this a project managers problem? is a client not understanding their needs? a project management characteristic? do all plans undergo this rescoping?

Project Path Graph

Simply put, as a project begins, the foundation decisions aren’t established and thus your ability to change and adapt is high. You haven’t committed yourself by means of platform integration or contract obligations, framework licenses and you haven’t committed to development spaces or logged meaningful hours. change is simple at this stage.

As you move along the project timeline, the variables change; you are literally building the project constraints. And thus the ability to shift outcomes that differ from the specified project scopes lowers, this is a reality in most if not all construction industries, including and not limited to the software verticles and most programmers understand this intimately. The ability to influence the outcome of a project depends on the project stage. The further you get into development the less of the ability you have to change the agreed project outcomes. This is why project development has clear and defined contract milestone, phases and agreements. it’s for protection of the endeavor and adds awareness to both client and developer.

That’s it for this rant, Thanks for reading it.