Several times I have been brought in at the middle or towards the end of a proof of concept project. Typically, a proof of concept (POC to save typing) or prototype is designed to show off some capability, give the viewers of the POC an idea of what the finished product will be like, and demonstrate that something is technically possible. Sometimes a POC is tied to hardware and the software controls the hardware, and sometimes it's a pure software project. The job handed to me in these cases is simple: assess the design, validate the architecture, determine the progress towards the target, manage the team, drive to completion, and try to manage the whole process on as tight a deadline and as small a budget as possible!
These are the projects I love. There's tons of pressure, and the development team has an interesting goal of designing something that probably hasn't been done before, may be stretching technology to a new limit, and basically "inventing" something new. There's a balancing act that is always necessary in POC projects between speed of code versus quality of end product, how much to put into the POC versus leave for the release product (and perhaps not show the viewers of the POC enough!), the need for pushing code quality with volume of code, and pushing the team without breaking or demotivating them. Then there's the budget: spend extra to get the POC out faster or with more features, but risk the POC doesn't do its job, or be conservative and control the budget at the risk of being late with the POC or having to trim features to get it out on time.
The development team of a POC project is often different than the team for a full-blown mature projects, too. There's more focus on architecture and innovation on the POC, versus incremental improvements with code bloat on a mature project. The development team themselves usually has a few gifted developers instead of a larger team of steady coders, but the trade-off is often idiosyncratic code. There's more push on a POC to get the thing working quickly and not focus as much on coding standards and code readability. And there's the ever ongoing issue of quality: does the quality of a POC have to be as good as that of a mature shipping product (but if quality is not there, a POC can be disastrous in a demo)?
All of these trade-offs and balances that the leader of the team must manage, while under constant pressure to deliver. In many ways, that is what makes the challenge of a POC or prototype all the more fun, at least for me. With a POC, I can get down and dirty with both the team and the code, usually far more than with a mature shipping product. And it is always a lot more fun to do something new, innovative and challenging than simply adding new stuff to an existing product.
But this fun comes at a cost. In my career I have never worked more hours than when working on POCs. They suck time, both from the development and the management point of view. Getting everything right, making sure there's no flaws in the design, ensure that the code is tight, and that the program does what it is supposed to do are all development challenges. Dealing with the team, and the rest of the company waiting impatiently for the POC is the management challenge, and often the bigger of the two as there's typically a lot of money tied up in a POC, not to mention potentially huge revenues down the road as soon as the POC becomes a commercial product. And then there's the always present danger of things just not working properly, and how you cope with those last-minute gotchas. It's a huge amount of work, but then, that's also part of the fun.
I love POCs! Bring 'em on!