
Why Project Management is important to startups (notes from Niel Robertson talk) - wastedbrains
http://devver.net/blog/2008/07/project-management-with-niel-robertson/
======
nielr1
Folks - i'm the one that gave that presentation. One thing I am seeing here is
a semantic assumption that PRODUCT management and PROJECT management are the
same thing. IMHO they are two vastly different disciplines and very little of
what I said applies to my opinion of PROJECT management (I could do another
preso on that alone). Project management is a book keeper and arbitrator
function in my view - not a decision maker about the final product being
developed. Many companies blend these functions, we intentionally separated
them as managing project timelines and gant charts is a vastly different skill
set than managing requirements. I suspect many people have a poor opinion of
Project Management (and the institute) because they blend the two functions.
But don't confuse the downfalls of many project managers (they have limited
consituencies - budget and timeline) with the Product Management process.

Hope that helps - glad this started some discussion.

Niel

------
edw519
Excellent overview. (But just an overview, there's a lot more meat on these
bones.) These are the things that go without saying, but no one talks about
because they aren't cool.

 _A spec is well written when QA can figure out how to test a feature based on
the spec._

A great test of your specs. Building test plans and development should be able
to proceed simultaneously and separately.

 _On gathering data, go out and talk to people getting more data points about
the problem you are solving until you start hearing the same things and can’t
learn more from talking. Then go work on it, knowing all this data._

Don't forget to talk to them in groups. Their disagreements (and there will be
disagreements) will provide some of your best data points.

 _Niel doesn’t recommend a developer also taking on the role of PM, as there
needs to be a tension between who represents the user and who implements the
product._

What he calls _tension_ , I call checks and balances. We hackers are all too
familiar what could happen when you develop in a vacuum.

 _The PM should be the most empowered employee in your company… Yes, even more
than the CEO_

This cannot be lip service. The first time the CEO overrules the PM, your
"project management" will lose all credibility and be worthless.

~~~
wastedbrains
Yeah, I don't follow everything he outlined. I think being able to do testing
with out a formal spec is good. Especially when talking about unit level
testing. Once you are talking about functional testing it is better to have an
outline of what exceptions and expectations should exist in the system.

Good point about talking in groups, letting potential clients argue over a
feature and resolve what they both think is best can be gold. It is a great
way to force people into some potentially different ideas.

~~~
edw519
_It is a great way to force people..._

It's also a great way to find out what's already going on. How could you be
expected to extract data points before they even agree with each other?

~~~
wastedbrains
In the end I don't expect them all to agree... but yeah finding out what they
are already feeling and agreeing about is important.

It is also really good to see what they completely disagree about.

------
pjackson
I'm not a fan of the "Project Management" discipline as described in this
article. But neither am I a fan of design-by-prototyping.

I believe that Agile methods are the way to get things done faster with just
the right amount of process. Agile teams shouldn't be allowed to get away with
not doing architecture, design, whiteboarding, feature planning, user stories,
QA, or UAT. Indeed, they are so important that they _need to happen all the
time_.

They SHOULD get away with not having to use the PMP-approved form, with self-
organizing rather than have tasks assigned, with not being "statused" every
week in a big sit-down meeting where a 200 line project plan is reviewed in
detail, and with embracing change.

~~~
ardit33
I agree. I am having the same problem, with this meetings, and when I missed
the last one, the project manager decided to assign me something that didn't
make sense, and I had to rebuff him, and kindly tell him working on that piece
of functionality right now was stupid.

Project managers should just keep track on what's going on, and leave it to
the technical team to decide on what to tackle first, or last.

------
coglethorpe
“The PM should be the most empowered employee in your company… Yes, even more
than the CEO”

This message was brought to you by The Project Management Institute.

I have yet to work with someone who is a PMP who has done anything but make a
project worse. Maybe I've just had bad luck with that, but I'm not impressed
with the job title so far.

~~~
alex_c
I have had the good fortune to work with exactly one good project manager so
far. He is good because he is intelligent enough to realize when he doesn't
know something, careful with the team he builds, depends on what his team
tells him (rather than ignoring it and going with gut instinct), and focused
on processes only insofar as they result in a good product (meaning he
approaches any "magic bullet" methodologies with skepticism but with the
possibility that they might contain one or two good ideas that make sense in
the specific circumstances of the project).

That's really a list of what other project managers do wrong, though, than
specifically what makes him valuable to the team.

~~~
markm
I appreciate the kind words Alex.

------
trey
First I didn't read the linked article but...

I have yet to see a PM that actually performed PM duties that yielded a net
positive for a company.

If the PM doesn't have authority over developers the position devolves to a
glorified QA position so that they are actually doing something useful.

If they are given authority over developers they add a level of politics and
stratification that ends up being a distraction to a team that otherwise works
well together. Software developers have a lot of power to affect change and
are generally anti-authority. Keeping an organization structure flatter seems
to make software developers more productive.

Given the choice I would avoid having a PM and just hire more intelligent
software engineers. A quality QA person can give you the same effect without
the mess.

Note that I am separating project manager duties away from product manager
duties.

------
ardit33
over PM - ing, is the death for any early software startup.

Get a prototype (wireframes). A basic engineering specs, and divide everything
you are going to do in tasks that don't take more than 3-4 days to complete.
Anything that takes over a week, should probably be divided up. Put all the
tasks in a list in a excel sheet, and start marking them down as they are
completed. Or insert new ones, as they arise. That's it.

I recommend to my competitors to get as many PMs as they can, especially the
ones that love Microsoft Project, and don't know how to operate otherwise.

Burocracy is a PM's best friend, as that's what they fundementally are. People
that track projects, and tell their managers on what's going on.

------
swombat
As the project manager on my start-up, I certainly agree that project
management is essential.

However, there are many ways to manage a project. The document-heavy method he
proposes is one that I used again and again back in my consulting days.

Unfortunately, this kind of project management is extremely ill suited to an
early stage start-up. Those documents all help reduce communications issues,
and they do so extremely well, granted. But if you're having enough
communications issues to warrant this in a 3-5 people start-up team, you are
completely and thoroughly fucked, and no amount of documentation will _ever_
save your ass.

With a small team and rapid development tool, I think most agile project
management practices are far better suited to deliver the application and be
able to react to market changes quickly.

Also, as others have pointed out, 30-second requirements? Yeah right. In your
dreams.

~~~
wastedbrains
He really wasn't pushing a document heavy, he thins man of the so called docs
could be in emails, with very quick statements. It just avoid confusion of
beginning down a path for a few hours, when there was a minor communication
error.

He said one of the things he hates the most is when you send a requirement off
to an engineer and 3 hours later you get back, a working feature,
documentation, and a spec. then if it doesn't match the initial concept a
bunch of time has just been blown.

Just to give some perspective, Niel is a CS grad and has plenty of engineering
in his background. He said he gets why engineers fight back so much, but it
hurts the project as a whole.

~~~
swombat
Well, reading the article, there's hints of a somewhat heavier process. For
instance:

 _A spec is well written when QA can figure out how to test a feature based on
the spec._

I'd reply that in an early start-up team, _everyone_ does QA. Again, if they
don't, you've failed. Dev silos in a start-up? Are you kidding? If anyone on
the product team doesn't know the product well enough to do the QA without
being told what to test, you're, once again, completely screwed.

Also:

 _It came across that it wasn’t important what system was used, but that
everyone at every stage of the project must write things down._

Again... if you're having to write _everything_ down to clarify
communications, you're pretty shafted. I know why it's important to write
everything down. I did work 4 years as a consultant, and in a corporate
environment it _is_ important simply because there is a huge potential for
miscommunication, and writing things down reduces that potential and also
covers your ass.

But in an early stage start-up, both of those tips will kill your start-up
much faster than any so-called "wasted time".

Ultimately, all of that advice is good advice under certain circumstances. But
not in a start-up. It's a different kind of beast, and I'd wager the author or
the speaker lack start-up experience to be making these kinds of statements.

~~~
wastedbrains
Niel is currently working on his 3rd startup, two successful so far. I think
he knows the early stage start ups pretty well.

I know what you mean about getting bogged down in writing everything down. I
have had a hard time getting away from verbal communication and just working
on my own as well. I can recall various times it has led to problems and
spending time on the wrong things though. I think he basically pushes to be
fast but still have some documentation, because the few missteps you make,
will waste more time than you think you are saving.

Everyone should be able to QA, but manually QAing or forgetting to QA
something because it was a weird edge case can really hurt or slow you down.
We try to deal with this by avoiding manual QA we don't want people wasting
time going through the product QAing it over and over, we rely more on
automated testing.

If you believe that a few short emails back and forth and IMs to keep people
on the same page means your shafted,I guess we just have a different value on
30 minutes of non development time a day.

I think in our last start up to much head down development killed the startup.
Which isn't related to the documentation vs non documentation issue, but was
still a PM mistake on our part.

------
nielr1
And ps - you can Google me to find out my resume. I have only ever built
startups - from powerpoint to sale. Since the first company i started when i
was 14 :)

------
gruseom
Well, let's ask the people here who work with and know about a lot of
startups: how closely is the presence of a project manager associated with
success?

------
jnovek
I don't really agree that you can go from "Hey, I've got this great idea!" to
a spec in 7 minute and 30 seconds for most features; for many of our user
stories we debated for hours. This, of course, might just be a sign that we
chose vague user stories.

Even so, importance of project management cannot be overstated. Even if
planning takes up most of the effort per iteration -- presuming that it's good
planning -- there's SO MUCH of value that will come out in the planning
process that you can't get if you just sit down and hack it out.
Maintainability is just one thing that good PM will get you.

------
sanj
This is incredibly important, to the point where I think you can characterize
chances of success based on having PM skills in your founding team.

