Black Holes in Software Product Management
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
- Anything that cannot be described cannot be understood/implemented/changed.
- Most of the time, professionals are focusing on short term “urgent” things compromising on the long term “important” ones (like Sai pointed out in my earlier blog).
- IT (Information Technology) is becoming a commodity day by day and it is better for companies to focus on their core competencies and build competitive advantage, and outsource IT operations. But obviously they should be knowledgeable on what has been outsourced and have the capability to track and monitor.
- The customer market is by one (customer)! Every customer that walks into a retail store is unique and a retailer who addresses those unique needs of each customer will be a big winner!
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.
Related Posts
Smart Grid Applications go on Cloud How Global Companies Fine-Tune Local Promotions Privacy in the age of Big Data The First Sprint in Distributed Agile – What to Expect? Is Travel and Hospitality Industry Already Up In The Cloud?
Recent Posts
My Interactions with Customers – Key issues with partners in outsourcing Testing The Smart Machine – A Win-Win Proposition Key CPG Trends & Implications Can Gamification help achieve better adoption? Customer Management Vs Customer Expectation Management View all
Most Viewed
A fresh look at metrics and the marketing funnel (1832) Different Views on Consulting (1608) What is Consulting? (1500) B2B Digital Marketing (1313) Can You Entrust Your Services Partner With Your Demand Reduction Goals? (1054) View all
Most Commented
What is the difference between Marketing and Sales? (24) An inbuilt mechanism for innovation: organic & ecological (16) Mumbai Dabbawalas (16) Everything That’s Marketing (16) Corporate Blogging: It’s All About Engagement (13) View all
Vlog
Creating Sanity Amidst Test Methodology Madness – Webinar Series Transforming Test Organisation MindTree Vlogs: Role of Independent Testing in the Manufacturing industry A Look Back and A Look Ahead Some Brands Never Get Old View all
Cartlog
The Perplexed Scrum Master What’s in it for me? (WIIFM) When you are an expert on something, where do you learn from? Mantras for Communities FAA-some View all





MindTree Blog Archives
Subroto Bagchi







Rohit P. Khare says:
I previously worked as project manager for a key government organization. My experience is that the biggest black hole in any project management is not involving the lower employees while studying the requirements.
The software team doesn’t become a part of the client’s organization. I did not mean physically but behaviorally.
Most project managers tap the senior management of the client and prepare the software blueprint depending upon their feedback. The result is that when the final software is deployed, it is not able to satisfy most of the client needs.
The most valuable input comes from the lower employees who actually deal with customers and use the core components of the software.
…………….
Rohit
http://softwarefindings.wordpress.com
Romby says:
Action reqruies knowledge, and now I can act!
Saiganesh Ramani says:
Few comments from me:
1. Estimation is always a black art. I have not seen any project in my life time that has predicted the correct number of effort days/months required – with 99% of the time seeing an overshoot of course. Software Engineering is just too fuzzy to make an accurate estimation. In general, other engineering activities have decent methodologies to estimate and we are still struggling in this area.
2. With the global workforce being the norm, Managers have very hard time figuring out ways to understand individual talents. But I agree this is something that organizations should work on understanding for their own good.
More comments later
Saiganesh Ramani says:
3. Scope Creep
It is always the things that are said in between the lines that trip us out. It is very hard to categorize hidden requirements as scope creep. One of the example that I faced with some of my earlier projects is that we had intense discussions with the customer on the requirements and UI interaction and we delivered everything both from a client and server functions, however the customer was expecting the same level of functionality in the Web UI at the same time and he has been seriously planning his deployment while we were seriously developing it in our app specific Rich Client UI. Very difficult to categorize this as a scope creep. (Your paraphrasing of Blind Spot suits this perfectly).
Lesson learnt by me: Having an additional (serious) discussion about deployability of product at the concept phase really helps. It resolves a whole lot of unknowns and also grounds the architects and the development team firmly on reality.
Indy says:
Please keep trhwonig these posts up they help tons.
product strategy says:
Software product management discipline helps in managing software products from its beginning to support. It covers strategic issues of managing products including technical and business roadmapping, resource planning as well as strategic and tactical planning. In this qualitative study, we interviewed six organizations to understand how software product management is implemented in the organizations.