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.
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.
Ironic as hell. As the programmer, I'm also generally the only person looking out for the user. Our project managers only care about hitting every bullet point on the invoice and coming in on budget.
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.
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.
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.
“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.
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.
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.
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.
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.
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.
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.
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.
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 :)
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?
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.
Hope that helps - glad this started some discussion.
Niel