tag:blogger.com,1999:blog-60512735620866154552024-02-21T10:06:59.439-08:00Experiences, Reflections and the odd point to ponder!This blog captures personal thoughts that can help me reach out to all the great professionals I have had the privilege to work with and get folks to share their own views and/or challenge my views. I will be trying to post new posts weekly.GShekharhttp://www.blogger.com/profile/04575250739820185110noreply@blogger.comBlogger11125tag:blogger.com,1999:blog-6051273562086615455.post-32805960562996745372010-02-20T22:14:00.000-08:002010-02-20T22:14:45.343-08:00Project success i= 80% expectation management and 20% deliveryI have seen enough project stories to see that inability to manage expectations internally or with the customer results in project failure. However since all project failures can be reduced to inabilty to deliver on time or with quality or meeting the scope or within budget (typically a combination), they look like they are always delivery failures. <br />
<br />
So how do we attack expectation management part?<br />
<a name='more'></a><br />
it is invaluable to align yourself with the customer and win his/her trust and then influence the expectation more in line with reality. Any analysis of failed projects will show that the disconnects started in teh first 30 days of the project. <br />
<br />
One rich area to attach expectations management ( implicit and explicit) is ASSUMPTIONS. Most stakeholdersr are aware of dates, costs and the requirements. however the underlying assumptions made by the vendor are either unrealistic or at time absent. these assumptions could be productivity assumptioms, third pary dependencies, or even expected cooperation from the customer. However the MPP view tends to give a false sense of security. <br />
<br />
How does one tackle these assumptions, which often are bandages to underlying project risks? <br />
<br />
In my view it is important to test the basis of assumption based on past 3 months experience or actively validate them in the first 10% progress of the project. Calling them out and either removing the blockades or redefining the project plan are ways out.GShekharhttp://www.blogger.com/profile/04575250739820185110noreply@blogger.com1tag:blogger.com,1999:blog-6051273562086615455.post-52189792664846768562010-02-03T12:58:00.000-08:002010-02-03T12:58:12.196-08:00When to write email and when to talk?This is an important distinction that I notice many employees do not consciously make. Often the choices are influenced by convenience not keeping in mind what would be most effective to deliver the outcome.<br />
<br />
When to write an email --> Only when you are conveying pure logic or facts <br />
<br />
When to pick up the phone --> when you you are conveying emotions or anticipate an emotional response from the other side. <br />
<br />
I have seen many emotional emails that make poor reading and I have also been in calls where logic is intimately explained. Logic explained on the phone cannot be traversed back and forth and hence is difficult to grasp on the phone. <br />
<br />
the above approach has worked for me and hope it does for you as well.GShekharhttp://www.blogger.com/profile/04575250739820185110noreply@blogger.com4tag:blogger.com,1999:blog-6051273562086615455.post-73374650638435494272009-12-22T00:57:00.000-08:002009-12-23T05:04:32.339-08:00Reflections on the indian cricket team's losses!Why is it that no one wants to see a match where your team is loosing and are super keen when your team is winning. I am happier watching re-runs of matches we won than those that we lost.<br />
<br />
Why is it that most movies have a positive end.? May be we like to keep the hope on and losses simply switch off some genetic button.<br />
<br />
Why is it that in an organisation ver few are interested in bad news and good news is over broadcast/ spoken/ emphasized atleast in official channels. One can really see this in sales presentations where wins become folklore!<br />
<br />
What about project failures, how much do we really learn from them? Are we even keen on doing so? I believe that we would any day gloat on a heroic effort where we managed to cross the line against all odds.<br />
<br />
Just me reflecting on my emotions and thoughts as India lost its 202/20 matches to West indies and England on successive days!<br />
<br />
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiC3Wx6VCToz7_ZiesDaUkBvC6GxkeKCO7Ezu2lKC88Og8chFjjdvZG9u3I04hyiany6AoJrh52HzWK2OdjODdwdYPz9hal8uR-O2Af3fSKr4UsCNN22NOCezlqGqc_Q-O_CtLtq4AXqSM/s1600/DSC_0244.JPG"><img alt="" border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiC3Wx6VCToz7_ZiesDaUkBvC6GxkeKCO7Ezu2lKC88Og8chFjjdvZG9u3I04hyiany6AoJrh52HzWK2OdjODdwdYPz9hal8uR-O2Af3fSKr4UsCNN22NOCezlqGqc_Q-O_CtLtq4AXqSM/s160/DSC_0244.JPG" style="clear: both; float: right; margin: 0px 0px 10px 10px;" /></a><br />
<div style="clear: both; text-align: right;"><a href="http://picasa.google.com/blogger/" target="ext"><img align="middle" alt="Posted by Picasa" border="0" src="http://photos1.blogger.com/pbp.gif" style="background: 0% 50%; border-bottom: 0px; border-left: 0px; border-right: 0px; border-top: 0px; moz-background-clip: initial; moz-background-inline-policy: initial; moz-background-origin: initial; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px;" /></a><br />
</div>GShekharhttp://www.blogger.com/profile/04575250739820185110noreply@blogger.com1tag:blogger.com,1999:blog-6051273562086615455.post-45962122839495152332009-12-12T01:35:00.000-08:002009-12-12T01:38:39.624-08:00A great Question for every product team member --Why are we doing what we are doing?As a member of a product development team, one encounters the challenge of there being no single customer and instead a "Product owner" becomes the Proxy" customer. <br />
<a name='more'></a><br />
The Product owner interacts with multiple stakeholders and based on different priorities (and pressures) builds the resulting product roadmap. Delivery team members live in the comfort that somehow the responsibility of priority rests with the Product owner and go about with blinkers trying to accomplish what is laid out. Yet in so many product development efforts, we do not achieve financial success and features built are no longer relevant. Product team members are left bewildered at the consequences despite putting all the late hours and at time face the devastating situation of the entire effort being shelved. <br />
<br />
As a team member how could you have prevented this?<br />
<br />
I believe that active questioning of what goes into the product roadmap by all team members is crucial to improving the odds. <br />
<br />
every team member has a right to know --Why are we building what we are building?<br />
<br />
the following steps could be useful for a quick analysis would be<br />
1. The target audience for the release : Customer or Prospect ( Some understanding of the segment being targetted wll be very useful as well)<br />
2. The reason for the release which could be,<br />
a. Cost savings for the end customer<br />
b. revenue adding for the end customer<br />
c. regulatory needs<br />
d. contractual obligation<br />
e. catch up with competition<br />
3. amount of revenues that will be generated <br />
4. likelihood of revenues that will be generated by the development effort<br />
5. Underlying assumptions for all of the above<br />
<br />
I know it reads like the business case of the product release, however in practice business cases are not built in this level of detail and it is useful to simply question the "Product owner" in a manner that puts the context for the overall delvery effort. <br />
<br />
Product owners in turn are bound to discover blind spots if all team members take upone themselves to get their own answer as to ---Why are we doing what we are doing?<br />
<br />
ACID TEST ---If none of your questions as brought out above result in the Product manager changing the roadmap over the next 2 releases then either you are not asking the right questions or your Product manager is Perfect!GShekharhttp://www.blogger.com/profile/04575250739820185110noreply@blogger.com3tag:blogger.com,1999:blog-6051273562086615455.post-63827663296865217642009-12-04T02:23:00.000-08:002009-12-04T04:09:15.710-08:00A really useful technique many project managers could use - Do you know baselining?...SO you are a project manager taking over a failing project right in the middle-- what would be your first step?---Baselining <br />
<br />
Far too many good project managers end up becoming martyrs simply because they do not use this technique. This used to be a question I often asked project manager candidates! <br />
<br />
<a name='more'></a>The definition I use for baselining is " the synchronisation of all configurable items of a project".<br />
<br />
In simple English it means you take all the latest versions of the configurable items of the Project ( Requirements document, Design document, MPP, Test Plan document, Latest source version, etc..) and then reconcile them with a baselining document which captures the differences among these documents e.g. if requirements document has 67 use cases but design talks of 58, then identify the difference. Similarly if the scope of the MPP is different from the requirements document then identify the difference and so on....<br />
<br />
You then set about reconciling these differences (from a contract/ customer perspective) with the Project manager handing over the project to you, so that all CI's of the project in perfect synch and you are now truly in control. All differences can be highlighted and also you get all stakeholder in "synch" as well. It is not funny to see the disconnects in larger programs.<br />
<br />
If you are taking up a project in the middle of a mess, you better do this in the first 2 weeks otherwise the entire mess will be inherited by you. This also is a line in the sand that you can draw to show progress from what you have inherited. <br />
<br />
Hope this is helpful beyond cracking interviews!GShekharhttp://www.blogger.com/profile/04575250739820185110noreply@blogger.com1tag:blogger.com,1999:blog-6051273562086615455.post-26131850954895284932009-12-04T02:07:00.000-08:002009-12-04T04:17:10.743-08:00One technique to help you work well in a matrix organisationA lot of us work in complex organisation structures that are organised across geographies, product lines and nature of work itself (In technology companies this could be Engineering, Professional services and Support). we then are subject ot directions and expectations of multiple "bosses" who typically operate at higher hierarchy levels. At a more nuanced level personalities and style of management of these "bosses" further complicate matters. <br />
<a name='more'></a><br />
For a professional working in such structures there emerge avoidable conflicts that can be traced to lack of specific clarity on how to operate within these organisation structures. <br />
<br />
The technique I have found useful is to understand that all your interaction points can be reduced to fundamentally 3 categories - the internal Customer, the internal Supplier and the Appraiser. Calling out the primary relationships and discussing expectations goes a long way in ensuring that you are well aligned in such organisations. <br />
<br />
I find the "customer- supplier" distinction more useful than the ambigous "peers". Do note that in a given relationship there may be a supplier and customer component, that together defines the complete relationship. <br />
The final category is the "Appraiser" and hopefully in most cases you have only one Appraiser!.(He in turn should take feedback from other internal customers and supplliers to better evaluate your effectiveness)GShekharhttp://www.blogger.com/profile/04575250739820185110noreply@blogger.com2tag:blogger.com,1999:blog-6051273562086615455.post-83668389936653763472009-11-27T04:00:00.000-08:002009-12-04T04:12:38.068-08:00Who is an exceptional professional?What is the main purpose of one’s life? It is constantly realizing your full potential”. “Even Grass grows”<br />
<br />
An exceptional professional is one who is constantly operating close to at his/ her potential at that point in time. <br />
<a name='more'></a><br />
You could also validate this by always asking yourself is this the best you could have done and then listening to your heart!<br />
<br />
The points below come from my personal expereinces and are not neceesarily complete nor are they universal but will hopefully be good starting point. <br />
<br />
What are the obstacles we face in our endeavour to be an exceptional professional?<br />
1. Lack of sufficient role models<br />
2. Peer environment influence of coasting along = chalta hain = resulting in passive dissatisfaction and tolerating mediocracy<br />
3. Environment Influence <br />
a. Industry influence – Service Industry – what you do costs $20 per hour but how much do you value it as ?<br />
b. Company and its structure how is excellence recognized? How are you encouraged to improve yourself?<br />
<br />
What are the steps one can take?<br />
1. Maintain a super strong positive attitude at all times<br />
2. Investing in yourself = learning new skills (not just technology but people skills as well) and Practicing what you have learnt. Treat your work environment as a laboratory<br />
3. Building a better understanding of the problem Challenging status quo – Is there a better way of doing stuff?<br />
4. Understanding the business and how we make money?<br />
5. Sell your ideas/ thoughts/ approaches at various levels in the organization.<br />
6. Benchmarking yourself with the best and exceeding them. <br />
7. Taking ownership of everything you are associated with<br />
8. Taking feedback – how can I be better?<br />
9. Giving feedback ---How can you be better and how can our working relationship be better<br />
10. Keep getting into unfamiliar territory (newer responsibilities) and give it your best.<br />
<br />
<<these farewell="" for my="" notes="" recent="" speech="" were used="">>GShekharhttp://www.blogger.com/profile/04575250739820185110noreply@blogger.com2tag:blogger.com,1999:blog-6051273562086615455.post-6798004090408704262009-11-25T03:48:00.001-08:002009-11-28T19:42:50.266-08:00the 4 dimensions to consider when building a product and Do you do that?Enterprise software is often built without looking at all dimensions involved. The selling approach unfortunately reinforces this approach and as a result a lot of buyers do not consider all the dimensions involved in making a complete well thought out decision. <br />
<a name='more'></a><br />
Product companies tend to build products without profiling their target customer segments well. This means that Products are built without knowing the size of the end customer, the nature of transactions, the competitive players in that segment and the unfulfilled needs. Often products built to do X end up trying to meet the needs of 3X or worse Y. Bespoke development being repackaged as a product offering often short changes this critical step. Unfortunately we have too many cases of products simply not fitting the bill and the failed projects around the same result in huge costs and opportunity losses. Profiling target customers is never too late and will only serve as a useful indicator of what is expected from the product architects! Periodic updates of these as markets change or as the product morphs to target different customer segments will only help in serving as a useful baselining of expectations. <br />
<br />
What are these dimensions and what do they entail? Enterprise software needs to address the following 4 broad dimensions: Architecture, Functionality Implementation, and Maintenance.<br />
<br />
A well defined architecture would meet the non functional requirements of the profiled target customer segment and these include expectations around Performance, Security, Extensibility, Scalability, Compatibility, Developer Productivity, Cost of ownership, etc.. <br />
<br />
Functionality is typically a huge focus for the product company but there are caveats. However often Product owners do not explicitly identify features that really differentiate their offering from competition, features that will help extract more dollars from existing customers. Often balancing the needs of existing customers with that of the prospects is not achieved. . <br />
<br />
Implementation considerations are another opportunity that proactive Product owners within a company do no capitalize enough. Experiences from the last few implementations do not seem to influence the product roadmap. Any customer would give an arm and a leg for a risk free and quick implementation (Often these are very high in the customer priority list but not given the due weightage proactively). <br />
<br />
Product maintenance creates a whole new set of considerations that can be addressed proactively at the time of building the product. Often product owners do not apply a 80/20 analysis on support issues of the earlier releases and take steps to eliminate some support issues or providing sufficient diagnostics to improve the turnaround time. <br />
<br />
Product owners do have a tough time trying to balance multiple priorities of various stakeholders. The current framework throws in another variable wherein they now need to balance the short term with the medium term which adds to the richness of the job!GShekharhttp://www.blogger.com/profile/04575250739820185110noreply@blogger.com0tag:blogger.com,1999:blog-6051273562086615455.post-32820916649642999632009-11-22T20:14:00.000-08:002009-11-28T19:43:43.064-08:00Quick Lessons from 26/11 for project managers26/11 has been a sober experience for all of us and is certainly evokes strong emotions. I for one would not explore this from all perspectives but try to quickly distill it from a project manager’s perspective. Analogies can be dangerous and sometimes the extensions may be distorting and comparisons weak. If I do hit those notes, do excuse me for the same. <br />
<a name='more'></a><br />
From the way I see it, the government is the Sponsor and the beauracracy is the project owner (and its team members). The event itself is a risk that manifested and all of us as Citizens (who pay tax and in exchange have a right to be able to conduct our lives safely) are end users. Clearly we do invest in Policing, Defence and Intelligence proactively to exactly eliminate these situations.<br />
<br />
There are 3 systems that owned the final situation as I see from an end user perspective.<br />
- The proactive risk identification system (intelligence system) to detect the risk<br />
- The proactive risk elimination system ( acting on the intelligence)<br />
- The reactive risk addressal system (fast acting response)<br />
<br />
I would like to submit 2 observations as the end user,<br />
1. All the 3 systems failed us as end users . This is substantiated by announcements of changing the existing systems (creating a central authority, etc..)<br />
2. Despite all the news coverage we do not know who owned these 3 systems. ( The design and execution of the systems)<br />
<br />
I have seen far too many projects where the lack of a single accountable owner create so much more latency, poor understanding, cross talk, coordination challenges, personality plays and blind spots (all of which I am sure contributed to 26/11). The result in most cases that I know is the project is a failed cause. <br />
<br />
I recognise that larger programs need larger structure and logical partitioning of the overall scope but the common theme of lack of clear accountability remains the same and inefficiencies get amplified for lack of clarity and poor alignment. . <br />
<br />
Another unique and predictable feature of headless failed projects is that no one gets sacked for the failure. Given lack of owners (the failure makes it even more of a pariah and hence even potential owners actively disown the project – and the lessons learnt are also never incorporated!)<br />
<br />
Another mini-lesson I note is the lack of communication to the end user (citizen) in precise way. The noise creators (media) took the lead in creating opinion and the project managers and the sponsors did very little by way of keeping the end users informed. AS a result the mindshare of the end users were lost. <br />
<br />
At the risk of extending the analogy one last time – When do we decide that the systems in place have outlived the realities for which they were created? Do we not need to inspect our systems as the environment around us changes?<br />
<br />
A final comment - I did start this post with a comment that this will be lessons for the Project manager but as I close this out. I feel it is equally (and may be a larger one) a lesson for the Government from Software engineering!GShekharhttp://www.blogger.com/profile/04575250739820185110noreply@blogger.com1tag:blogger.com,1999:blog-6051273562086615455.post-2030818024541421212009-11-21T21:48:00.000-08:002009-11-28T19:44:18.364-08:00Is lesser more? - Lessons for product companiesThe one significant difference I notice between Microsoft & Google as a product philosophy is while Microsoft tries to add more features, Google is minimalistic. Both happen to be at 2 ends of a spectrum. I acknoweldge that the comparison may be not entirely holistic and the product segment/ application / etc... all do play a role. However the merit of my observations hopefully is not diluted.<br />
<a name='more'></a><br />
My personal preference is the minimalistic approach. I became aware of this preference since my college days when the scientific calculator I used has more than 100 functions and I would go about getting my work done with about 25 functions. Most functions were derived from the 25 and hence I need not have known the remaining function. Happily I did confirm that I was not the only oddity and the majority of my classmates fell in the same category. In my view, the reason is more sociological where most of us try to use limited options instinctively as a mechanism to handle information overload. <br />
<br />
The point to consider is given its existing legacy, Microsoft will find it very difficult to become minimalistic (across its existing users there will always be someone who will be using the more esoteric functions) and they will find it far more difficult to create THE minimalistic set to the majority. As Google goes for its next versions and slowly starts adding features will they fall in the Microsoft feature trap?<br />
<br />
One can also extend the Microsoft dilemma to most other product companies. In my observation, product companies tend to over invest in adding more and more features, without considering the cost benefit of these features. A lot of features come in because competition provides it, some product manager likes the idea a lot or it was done bespoke for one customer and can be brought in for free! The real cost of losing the minimalistic approach is compromised and the cost of maintaining a low value adding feature for ever is not considered. The odds are in most products there will easily be 20% features which can be cut out overnight without any customer missing them! (A bold hypothesis – that does not have much data but just a number to stimulate a conversation)<br />
<br />
So what can product companies really do? All products can invest in usability that much more. Making your products intuitive, consistent and easy to use are huge opportunities. A favorite definition on usability is – “the need for a user manual means that the product is defective”. Look at the way you learn to user your mobile phones, microwave ovens, printers, laptops, etc.. (How many times have our referred to the user manual and how you could have creatively eliminated the same with better design?). The lack of usability will also mean a lot of features never get used!! (despite training and documentation!!)<br />
<br />
Another area that enterprise products can proactively over invest in the non-functional capabilities: reliability, performance, scalability, security, etc.. <br />
<br />
SO how do we handle increased fucntionality needs of users?...Is better configurability a better answer? - perhaps so, I do think we can more richly personalise the functionality by looking at the unique needs of each user segment and exposing the appropriate features.<br />
<br />
All of the above observations need much more elaboration ..but will try and cover it in a separate blog – I am dangerously close to my self imposed 500 word limit!GShekharhttp://www.blogger.com/profile/04575250739820185110noreply@blogger.com3tag:blogger.com,1999:blog-6051273562086615455.post-75577830737431788172009-11-16T23:15:00.000-08:002009-11-28T19:44:47.497-08:00On helping others...One of things that gives me a high is being able to make a difference to another human being. Over the years I would like to believe that while I have been able to help a few folks along the way and I have been fortunate enough to meet people who have made a difference in my own evolution. <br />
<a name='more'></a><br />
Among other things, I would like to use this blog as a vehicle to share my own experiences and also stay in touch with the many professionals that I have had the privilege of working with and where possible capture our interactions for the benefit of the larger community.<br />
<br />
Based on my personal experience, here are some thoughts on the subject of helping.<br />
1. Helping only works if someone explicitly asks for help. Non-solicited advise can easily fill a few trucks but will not result in an ounce of action. <br />
2. The act of helping does not place the person helping out in any higher platform. The act of giving is a responsibility and the one who gives also receeives. <br />
3. I do not have expectations from the person whom I help, the process and the interactions itself are reward enough for me. <br />
4. It is easy to to suggest what is to be done but actually executing it is what makes the BIG difference. Execution is everything, I use the example of the advise on losing weight (eat lesser burn more calories--but it is so much easier said than done!)<br />
<br />
To meet the above objectives I would like to use this blog to periodically share my personal experiences, dilemmas, failures and learnings. If some readers start newer threads that will even better!!<br />
<br />
Before I start, I must warn you that this whole blogging experience will test my own persistence and will also be driven by your feedback and a periodic nudging. <br />
<br />
--looking forward to hearing from all of you!<br />
<br />
Shekhar<br />
<br />
PS: I did fleetingly think of writing under a pseudonym, but quickly decided that I am what I am and I do not need another avatar!GShekharhttp://www.blogger.com/profile/04575250739820185110noreply@blogger.com0