Why Project Management is important to startups (notes from Niel Robertson talk)
devver.net
devver.net
Hope that helps - glad this started some discussion.
Niel
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.
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.
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?
It is also really good to see what they completely disagree about.
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.
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.
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.
That's really a list of what other project managers do wrong, though, than specifically what makes him valuable to the team.
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.
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.
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.
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.
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.
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.
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.