Hands-­‐on  or  Hands-­‐off:  Which  approach  suits  IT  business  heads  Have you come across situations where business heads in software organizations

• Are uncomfortable in facing the development team. As a result, they don’t mingle with the teams easily and use authority of their position to demand results?

• Are uncomfortable talking to customers about any technicalities of the project and restrict themselves to discussing commercials?

• Are found inadequate to take proactive measures when software delivery results are not up to the expectations?

Well, the above scenario is not too uncommon and there are many reasons for it. A business head in an IT organization can get into that position from a variety of career paths such as finance, HR and sales. Not all of them would have passed through the mill of end-to-end project delivery to understand the nitty-gritties of software delivery. And apparently many of them don’t need this understanding for their day-to-day functioning as their typical job involves meeting customers, building relationships, discussing commercials and closing the deals while delivery is taken care of by project managers. In summary, many business heads who get into that position laterally don't have background in software delivery and don't need it either for their day-to-day functioning in business matters but face certain limitations while dealing with delivery. Therefore, the question that arises is whether this hands-off approach is just fine or the business heads have to do something to become hands-on? In other words, do business heads need a certain level of awareness about software project management? What do they lose if they don’t have that awareness and what do they gain if they develop that awareness? As we will examine in this article, business heads stand to gain tremendously if they develop a basic level of skills in project management and there are 3 main reasons for doing so. In order to understand the 3 reasons, we have to first make clear the interrelation between software delivery results and business results at a parametric level.

Impact of software delivery on business results

While it is common knowledge that a high quality software delivery can lead to better business results, what is not evident is how it happens. Skill set of project managers and processes are two key areas of delivery excellence. Process and its skillful application result in improved delivery metrics. And some of these metrics directly translate into business results including topline and bottom line growth as shown in the diagram.

 

   

The range of skills and process areas in software delivery is quite vast and trying to improve everything would not only be a poor choice from an ROI perspective, but would be ineffective as well. Apart from the 23 process areas that CMMi lists, there are other areas that CMMi doesn’t touch. Refer " " for more details. There are skills such as estimation, requirement elicitation, requirement management, planning and tracking, risk management, test management, quality management, team leadership, communication to name a few. Training future project managers on all the skills relevant to project management would be as much of a syllabus as that of a master’s degree in project management which organizations can ill afford if all of their staff have to go through it. Therefore, choosing the right subset of skills to train future project managers, choosing the right process areas for rigorous implementation are key to success and this is where the business leader has to play a key role. The business leader has to provide direction in ensuring that the right skill sets and process areas that suit their business context are chosen. And driving delivery excellence in such a way that improvement in delivery is tracked all the way up to business results is also a responsibility of the business leadership. Hence, a business leader needs some high-level knowledge of software project management to be able to make the right choices, drive delivery excellence and ensure that delivery excellence translates into business benefits.

Relating delivery excellence to business results

Going into further details, the choice of process areas and skill sets has to be based on the delivery parameters or metrics targeted. Carving out a road map for delivery excellence has a method to it; the business head has to first choose the delivery metrics that have maximum impact on business results in their context and then choose the processes and skill sets that can specifically improve these metrics. There is a wide variety of metrics available in the software industry and a business leadership has to choose those metrics that make sense in their business context. This is a key area where thought leadership of the business head plays a crucial role. There are a variety of delivery parameters or metrics at various levels of the organization and each has an impact on different business

parameter as illustrated in the diagram. The business leadership should have an understanding of this relationship.

In summary, choosing the right delivery metrics to target, choosing the right set of skills and processes to improve the targeted metrics is a responsibility of business leadership. Even if this is done by delivery teams or a hands-on delivery, head, it is the responsibility of business leadership to get it done.   The 3 reasons for business head to learn a bit of project management Given the above explanation of how knowledge of software delivery is essential to achieve business results, here are the 3 specific reasons as to why a business head should have some hands-on knowledge of project management: Reason 1 – To make the right strategic decisions for delivery excellence: For software delivery excellence to yield business results, a proper road map has to be carved out and has to be driven incessantly. A business leader with at least a surface level of delivery excellence will be able to create the right focus (Read " What the CMM and PMBoK don’t tell you " for more details on why smart choices are required), ensure that delivery excellence is driven properly and track a long chain of delivery parameters all the way up to business results. Reason 2 – To be effective while interacting with customers: Customers, quite often like to test the vendors during their coffee shop conversations. When they bring up topics of software delivery in informal conversations with the business head, the business head should not land up being embarrassed and limit himself only to commercial details. He should be able to engage in the conversation in some meaningful manner. Secondly, customers don’t understand delivery models and place unreasonable demands beyond the normally unreasonable demands. For instance, customers take refuge in agile models and use agility as an alibi to lack of clarity in requirements. They would like to change the requirements in an unlimited manner and yet expect the vendor to deliver all the requirements within the fixed-price contract. The business head should be able to understand the implications of such demands and pitch in to negotiate with the customers when the delivery teams cannot handle the situation by themselves. This ability to deal with customers requires the business head to possess a certain basic level of understanding of software delivery.

Reason 3 – To provide motivational leadership to delivery team instead of using authority: Whether one likes it or not, the software field is full of jargons that creates a barrier for non-s/w person to freely interact with s/w teams in a meaningful manner. Jargons make it difficult to get to the point and this difficulty deters typical business heads from becoming hands-on, and freely interact with the development team. The jargons make the business heads isolate themselves into a closet and only use authority to get results from the development team. The beauty about these jargons is that it takes less than 5 minutes to appreciate the essence of each jargon and if a business head can burst all the jargons by investing sometime, he will be able to interact freely with the development teams in a meaningful manner and open up ways to inspire and motivate them. Hence, the business head has to invest time to understand basics of project management to be able to burst jargons, interact freely and provide motivational leadership.

In summary, a business head can drastically improve software delivery and hence the business by investing in learning basics of software project management.

If you are a business head reading this article, what would your response be? Else, if you have seen business heads functioning what would be your recommendations to them? Share your insights here.