This week in pm-clinic: the “poof” of concept
This week in the pm-clinic discussion forum– preventing “poof” of concept:
For months I’ve been pushing my VP to fund a project to enable our websites to produce and use RSS feeds (including newsreader like customization) – I was turned down every time, until yesterday. He’s given me the green light and assigned my team to someone else, but I only have a month, of a single programmers time, to prove to him the value of my idea.
He’s given me no direction on what he expects to see in a month, or what I need to do to convince him and other VPs to finish the project. I’ve never managed a short term, high profile, proof of concept project before and I’m thinking now I should have just kept my mouth shut (yes, I’m scared).
Now that I’ve bought the ticket, how to make sure it’s a happy successful ride?
– Avoiding “Poof” of concept (POC)
In my opinion, proof of concept doesnt have to be built from scratch.
Especially if the solution has been repeatedly implemented by other teams across the world.
I wonder how any web developer would feel if he’s asked to produce a web portal like yahoo.com as a proof of concept. Eventually it is important that proof of concept just demonstrates that the mission of the project/product is achievable with the resources at hand.
The solution therefore is usually to re-use code that is in the open domain and achieve a functional solution to the problem. Forgetting the low level design rules and concentrating on achieving functionality to spec is more important.
You may not have to ask for directions to the goal. You would define the goal initially and obtain feedback on whether it was the expected goal or not. VPs would hardly know what you’re talking about until you show them what you’ve achieved. So a quick prototype followed iterative feedback and development cycles might seem ideal in this case.