On a high level, project management is like managing a machine -you provide the input and then after some time you see the results. For example, if you were to work in a brewery, you would expect the quality of the beer to be directly correlated with the quality of the materials (which is the input!).

In this article, I'd like to tell you about my approach to project management, mainly, regarding how I handle IT project management tasks or what I call the “The Box Approach”.

I just wanted to have an excuse to use this gif

The Box Approach

For every task you assign to your team it goes through three distinct stages. The very first stage is where you specify the input (for example: a task to be done and other contextual information). Then, there's the Magic Box which is the "real work part" where you as a manager more often than not do very little work as compared to the other two stages, outside of monitoring and responding to questions. And finally, there's the result stage where you see the results of your work and I do mean your work - creating valuable input for your team to perform tasks, is what you're meant to do.

The input

The most critical part of any task is the input, this is the part where you as a project manager needs to do your best. You need to provide quality instructions for your team to ensure that you get the result. It is possible to always assume that everyone will do their very best to misinterpret whatever instruction you provide. And no, it's not because they're dumb, your input was vague and open for misinterpretation.

"Always assume that everyone will do their very best to misinterpret whatever instruction you provide"

So how does one provide better input? It's simple, you need to provide input that describes the results as carefully as possible. The best is of-course to show the results; the second best is to show something that represents the results, and perhaps the worst is a quickly written bullet point list of tasks.

My arbitrary ranking of input

Show the result
Images with description that represents the results
Detailed description of the results
Some bullet points you wrote down quickly before the meeting started

So how do you "show the result?" Luckily the internet has provided an endless source of tools to achieve that. Personally, I prefer Balsamiq Mockups (not sponsored, just love the tool so much). There are plenty of alternatives - some will allow you to do more graphical stuff. But let's not kid ourselves, leave the graphical stuff to the artists.

Using Balsamiq mockups, I'm personally able to create an interactive mockup that allows my team to see exactly what I want to have, and moreover they'll be able to use it and critique it. Here's an example of a very quick interactive mockup I did for this article.

Of course, just providing an interactive mockup of a user interface is not enough, more often than not, you'll want to explain the functionalities of each of those buttons you put on the design. For that purpose, I suggest using graphs. Personally, I like to use yEd Graph Editor (it's free!) as it allows me to quickly create very detailed graphs. Here's a quick example of how I'd make a graph to explain the login logic for a website.

The Magic Box

So this is the second part, this is where your skilled developers step in and turn your input into results. Most of us, the managers, are technically not able to (and should not) interfere with this process. There are a few dos and don’ts that we should keep in mind.

The don'ts

Don't ambush your team members. Believe it or not, they're doing something very complex and random, unexpected feedback is more of a distraction than a correction- especially if you were looking at something that was work in progress.
Don't get angry about misunderstandings. Figure out what went wrong, ask your team members how they interpreted it and use it as an opportunity to learn how to provide better input!
Don't provide estimates yourself. Ask your team first! You don't know accurately how long it takes for a development task to complete. Sure, it may sound "easy" (if it actually is easy, do it yourself). But, believe me, your team members should be more qualified to judge that.

The dos

Schedule review meetings, ask your team members for when you can sit down and review it and when they want to discuss feedback. Generally, you should have this on a regular basis.
Inform your team members if you make changes, preferably before you do them. And if you know that something may change then note that down in the task.
Ask for estimates, and plan for delays. Estimates are just that estimates, not promises. I see a very common trend that people seem to interpret estimates as promises. No one truly knows how long it will take to complete a development task, so always plan for the worst.
Write things down, did you have a discussion with your team members and defined something further? Write that down into the task. Everything that explains how to complete the task should be written down, preferably while discussing the project with your team members. If you update the task in front of them, it will help them remember the changes.

The result!

So you have gone through the input. Your team have done the magic and now you're sitting here with the results. Most likely at this point you've forgotten the details you wrote down for the task. So step one should be to check the input again before you review the results.

By reviewing the task before the results you'll be sure to avoid missing any details you have written down. You could print out the task and then use a marker pen to highlight the things that have been built. By that way, you have guaranteed that the output is a direct result of the input and a way to spot what may have been overlooked. To your surprise, sometimes, you'll realize that those things weren't needed at the first place. So always try to find out if they were overlooked or unnecessary.

At this point you'll most likely be in one of these three scenarios.

The result is great and according to your input

Great! Praise everyone and brag how awesome your team is.

The result is great but not according to your input

Great! Praise everyone, and then figure out what you did wrong in your input. Most likely this means that you don't actually understand what you're working with. Own up to it, sit down with your team and do everything possible to further understand the needs of your team members. If you're making websites, then study websites. If you're making beer, then study the art of beer brewing.

The results is not what you wanted

I'm going to ignore the scenario of your team basically not doing what they are told, because I have never experienced it. In fact, every time I have had results that did not align with my expected outcome, it's been a direct result of my input being bad. So back to the drawing board, find out why your input leads to this result, and learn from it.

Some project managers tend to think highly of themselves, as if they are "The boss" but no, you're a part of your team. The difference is that your team members’ value is measured in the work they do, and your value is measured in what your team does. So, do everything in your power to make sure that your team is performing as well as possible.

"Your team members value is measured in the work they do, and your value is measured in what your team does."

Keep that mantra in mind, and always improve the quality of your input, the quality of your management while the work is performed by your team.

Final notes

This is the first of hopefully many articles I write about project management. The idea for this article came out after discussing with a very kind salesperson who was pitching me a project management tool. He asked me how often my team at Aurora Digital "messes up" and I told him “never!”, which made him ask how is that possible? Every IT project he's been involved in is either delayed or over budget or a combination of both. My reply was to say it sounds like he's been in very mismanaged projects.

Please let me know what you think about my approach to project management. Feel free to connect with me on LinkedIn, tell me what you liked and disliked. I would love to learn more from other project managers! :)