I just being through 2 very unproductive mandays, which I think if I tell it to someone else their typical response will be "Pal, get used to it". No, dude, that's not the way I deal with counter productive activities.
"Do the best". A famous phrase that you keep listening from positive a.k.a optimistic people. I agreed. However under circumstances, obtaining the optimal result is just intractable to realize. If you coming from a background of data mining, statistics or other optimization related domains, you should know the importance of compromising for local optimum solutions. Heard about trade-offs?
Another good example, one of the project manager in the company that I know asked me: Hey, is 3 months enough for the end to end delivery of Project A? In fact, without knowing the scope and resource constraints of the project, I'm actually doing a bad estimation if answering the question. The moment I found out about the pricing of the project, immediately I would be able to commit some timeline for it. Basically, at the end of day the project will need to achieve it's "best" by trading off the scope/resource/time/cost because avoiding cost overrun and delivering the project on time are the primary objectives as far as I'm concerned.
Moving forward. Proof-of-concepts.
Many people don't really get a grasp about what REALLY is POCs and perhaps confuse it over other activities such as POTs.
IMHO, POCs should exhibits the following characteristics:
1. Clarifying and demonstrating the understanding of customer-focused concepts.
The key point here is that you can't go wild and simply do a POC without knowing the concepts that are high priority from the perspective of customers. By doing this, you can guarantee certain level of buy in about your solution.
Counter productive direction: Do things that you care, do things that you think are advanced and do things that cover everything else in the proposal.
2. POCs are for elimination of risks
"I need the new POCs by tomorrow". Sounds familiar? Of course if the presales team is strong their existing POC assets should cover most of the variations of any future anticipated POCs. The worst case scenario is you don't have present materials to leverage and you don't know what're the customer expectations (Clueless about their wanted concepts). The risks include you might misled your audiences (Intended?), misalign their expectations and miscommunicate deviated information to your implementation team. The reward is the same yet the risk is higher. Quantitatively (if all the aspects are really quantifiable) in statistics, the expected value of POC return is higher per unit of risk (standard deviation).
Among some of the best practices I worshipped during my days:
1. Perfecting sub-optimal solution, rather than pursuing rather disabled global optimum.
2. Pick the most restrictive constraints and use it to calibrate the other constraints. Pessimistic way of doing thing. Things will go wrong if you ever thought of it once that it might goes wrong.
3. Avoid using real customer data set for POCs. If unavoidable, the earlier you got your hand on the data sets, the lower the risks you need to manage. Non of the customer related concepts that I'm aware of really induced the need for using real life data. Most customers are willing accept if your POCs are using fictionous data which are "real" enough to prove the targeted concepts. Don't use junk sample data of course.
4. Integrated POC from a Consortium
Avoiding complex integrated POCs which otherwise can be done independently. Remember, the idea is to prove concepts and not to complicate matters. If the concept in question is to demonstrate the ability to integrate solutions as a big whole, make the integration points clear and concise and make POC just to highlight these integration points. Most of the time, customers just want to know where are these integation points during POCs, rather than seeing the actual integrations itself.
5. Know your audiences
Don't ever try to out smart your audiences by talking to them about matters outside their knowledge domains. Yes, they might salute your "knowledge", yet this defeat the purpose of POCs. They're confused instead.
The 5 values of XP methodology are:
Communication
Simplicity
Feedback
Courage
Respect
No comments:
Post a Comment