Guest Blog - Andreas Sundgren - Project management for entrepreneurs.

8 simple rules to succeed at project management by Andreas Sundgren, Head Guppy and founder, Microproject.com

Scandinavian Startups invited me to share my view in regards to project management for entrepreneurs.

Recently I and a small team designed, built and released a cloud based project management tool, www.microproject.com

Before Microproject I worked as CEO and am privileged to be one of the founders of the finest, most innovative and finest looking in MI software, Toontrack Music. I have been part of, seen and overseen a few projects from start to finish.

Describing project management

I almost always think of it as a process that is projected to become a product of some kind, from conception. Most of the processes I've been involved in, the goal was  conception of products and their subsequent delivery.

My thoughts here are inevitably colored by that background and so will the thoughts on how to run projects. I will use a vocabulary that is almost all about delivering product. All about shipment. I also need to add here that the thoughts I'm conveying here have been conveyed before by others. Not that they don't bear repeating.

To me, a project almost always consists of taking an idea, something fairly untangible, and guiding it to tangibility, deliverability. I am possessed by this. To finish. To go to market.

I need to  also add that I have been on both sides of the fence, I’ve found myself fighting moat points, droning on and on in full awareness of the dangers of hugging the whale, as well as having the courage to make the right call. I, and the people I’ve worked with, have failed and succeeded and we all, of course, need to be prepared to do both.

Regardless of perceived success or failure, the process of getting something from spark to shipment never ceases to fascinate me. It is watching creation happen, albeit on a small scale, and with known components.

The trick is of course to retain the original, the core of an idea, the spark that gave it life while also taking into account the creators and builders involved, the outside influences that will inevitably change the original idea and its execution over time and still end up with something that, because we're running businesses, resembles something that a market wants to pay for.

The simple start -  formulating a guiding document.

Apart from that huge tome of a product/project spec you’re going to write, also take the time to describe what you are about to create on half a page. It won’t cover everything, it can’t cover everything, it shouldn’t cover everything, but try to describe the core of why this specific project, this specific end result was conceived as important for you or for your target audience.

Speak the same language.

Make sure that when you use keywords in a discussion on moving forward in a project that those keywords are understood the same by everyone in the process. I have seen so many group hug agreements within in a team crash and burn because people were using the same words for very different components in a process. Make sure you speak the same language.

On Consensus; Make the decision - move forward...

Consensus is nice and cosy but at crucial moments it might be the worst thing to cultivate. Do not shy away from making a decision because you don’t want conflict. Fight. Make the call. Then move on. Better save time on a bad one than to drag out infinitely to in theory be “sure” that you’ve got it right. Time comes at a higher cost than the possibility of a faulty decision.
...and yes, failure is an option.

You will fail, get used to it. It won’t be "that one" decision. It will be the changing external world, the quality of your convictions,  misjudgement in the  idea basics. Or the fact that you shy away from conflict. What matters is not failure as such but what you draw from it in terms of knowledge.

Didn't you read my essay? - on keeping it short, and not trying to get your arms around a whale.

I am a memo writer. I write essays on the heart and soul of a product or a process. No one reads them to their complete end, much less try to disseminate what I actually mean. Why? Well I used to think it was disrespect. It never is, with few exceptions. It is usually just a fact of life that one man's pie is another man's soup. Keep it short. Use the vocabulary that you have agreed upon.

If you can’t explain something fairly compact you need to think about why. Your idea should be graspable, not whale-sized. As soon as you see yourself getting long-winded there’s a signal that you’ve got one, a whale. I promise, neither you, nor anyone else, will be able to get their arms around it.

It is very funny, I find, that this part of this blog-post is the longest one. A whale?

When in doubt - go back to the start - do not re-construct reality.

There are moments within a project when there is doubt. Although they usually precipitate a hard discussion, conflict or disagreement, hopefully followed by a decision, they can also give birth to reality construction where a group builds an alternative (and need I say fictious?) reality to support the notion of a change, small or big.

This is much more dangerous than fighting a point. When you future construction happening go back to your starting document. What is in it? Why did you start this? Where did you see it going back then? Constructing reality almost never means simplification of a core concept.  The simplicity can be found in your starting document.

The deadline is holy - when you can’t keep it.

A deadline is holy when you can’t keep it. When your part of a project is about to miss deadline, hopefully for a good reason, put up the red flag and communicate at the very moment that you have the realization. Explain why. Again, be specific (and solid) when it comes to why. Do not wait until the milestone meeting. This is about respecting the work of others.

Release something that works - don't wait till,presumably, it works better

Most of what you imagine as crucial in a product is stuff that very few of your intended audience have actually asked for or even want. This is not the same as only building features or services that have been asked for but it is a good guiding light when the moment comes and a project actually has to finish and go to market. Release something that works, not something that will presumably work better for an imagined customer in a non-defined future.