This blog is a continuation of my previous blog “Blind Spots in Project Management“. Thanks a lot Sai Ganesh Ramani and Naresh, for continually giving your points of views. In this blog, I am touching upon some of your comments on the earlier blog as well.
I had an opportunity to fly from Bangalore to Delhi on a business trip last month. In both these airports, the aero-bridge for boarding/un-boarding the passengers were not used. Is it because of Gate unavailability or aircraft (Airbus A320) type support for the bridges, I am not sure. But it is an inconvenience and shows poor planning or implementation in designing/running the airport. (When will we build an aerotropolis?)
Last month, thanks to iCMG organized “CXO Dinner Meet”, I had the pleasure of listening to John Zachman in person. Though some of the interesting points that he presented were in the context of the importance of Enterprise Architecture, at the micro level, those points are applicable to product or project management as well. His points were
I happened to read the article “IT does not matter” by Nicholas Carr, which reiterated point #3 above. Though IT does not provide competitive advantage any more, it has become an operational necessity (like electricity) without which the business function will stop. (The competitive advantage can be brought in through specialized programs based on Analytics/BI etc. which are not operational initiatives though.) Depending on the success and adaptation of cloud computing technology/methodology, IT is going to be even more commoditized. Like I mentioned in my earlier blog “Cloud Computing – Been There, Done That!” the companies which can reach out to servicing the SME market might become a big success.
With all these in picture, the operational IT is better outsourced (I am not saying offshored!) to the vendors who are better at IT and business companies can concentrate on building their core competencies sharper.
This was reinforced with my personal experience of renewing my driving license at the Bangalore RTO. Even after doing a complete research on the internet and RTO website & taking help from the help desk person at RTO, I missed the photo shoot at RTO. Nobody informed me about this procedure and it was nowhere mentioned either. There is no complete instruction set available anywhere! To give the photograph, I had to drive back to RTO again another day. (On that day, while I was getting out of the car, I received an important call and with that distraction, got locked out of my car, which by the way happened for the first time in my 16 years of car driving experience. So, I had to go back to my house, get the duplicate key, get on to the car and go on!) In essence I had to apply for half-day leave, not to mention about the petrol/money/time wastage. If I had given the same work to an agent at the RTO for a petty amount, I would have been saved off all these hardships.
When there is not enough information readily available and when it is not our core competence, it is better to outsource the job to an agent/vendor. This experience again reinforces my blog “Travel Agencies are here to Stay“.
In this context, the success of a software product depends on the important points mentioned in my earlier blog and some more are given below. A software PM/DM’s role becomes much more important from a customer business perspective, since the responsibility has increased. As Naresh commented in my earlier blog, the software product management is a complex subject and the style/execution/approach varies from product to product and life cycle to life cycle.
The following blind spots can become black holes sucking project funding, either through rework, schedule/effort variance or the complete product objectives not met on time.
1. Incorrect Estimation
Not employing the right estimation technique and right experienced technological/functional people can become a major issue in the software product delivery. The estimation could be far from reality (either positively or negatively) if the functional domain, requirements and technological landscape was not understood by the estimation team correctly.
For example, there are instances of reinventing the wheel for a product. In one instance of my experience, there was a requirement for an EDIFACT parser as part of the development. Construction of the same came to around 3 digit staff days whereas there was a tool available for the same in the market for a negligible price, with an integration effort of 10% of ground-up construction. It also saved all the rework/defects that could have come along with ground-up construction effort.
During estimation, the functional, technical and market knowledge helps in identifying the right tools which would help the project success.
2. Understanding the Team and each member’s talents
Forming the right team in place and knowing each member’s talents/skills/knowledge is also critical for the success. Skills and Knowledge can be acquired through self learning, training and on-the-job experience. But talent cannot be acquired through any training.
(I am a fan of the book “First, break all the rules – what the World’s greatest Managers do Differently” by Marcus Buckingham. The concept is explained very well there. For example, a programmer will excel if he/she has got problem solving talent (where all the data required for solving is present) and a system analyst will excel if he/she has got formulation talent (where the analyst needs to think through all the scenarios).
But the very nature of IT industry operates in such a way that people have fast progression without having the opportunity to develop the talent required for the role. Being unaware of such mismatches of roles vs. talents, and not taking enough counter measures to normalize the impact, will have an adverse impact on software delivery.
3. Lose control of Scope/Requirements
As a PM/DM, whether there is a financial impact or not, change of scope should be recognized (first, need capability to understand the change), well documented and all the stakeholders to be informed. Loose requirements/scope normally leads to most of the product failures. The PM’s ability in leading the team, keeping the stakeholders in constant communication and negotiations play a very important role here.
4. Metrics, Tools, Processes and Reporting
Choosing the right list of Metrics for each of the engineering phase of the product development/maintenance, choosing the right tools and setting the right processes and life cycle will help avoid these black holes which drain the company’s budgeted funds. Each and every product and its stakeholders are different and choosing the right customized life cycle model (water fall, agile methodology, iterative etc.) and having the stakeholders engaged through reports will avoid major surprises.
Your comments are most welcome and we can learn from each other. Please let me know your views and see you again later.