All the stakeholders at the table

intersecting circles abstract

“Let’s get all the stakeholders at the table” is a common charter when businesses decide collectively to invest in a software development effort to benefit business functions. It’s an important statement. Enterprise software is unique among all other forms of software because organizational consensus is so important. In fact, consensus challenge can be more important than technical challenge.

Unfortunately the IT team are often not included during this initial stage. Business leaders, along with business and operations stakeholders, generally will meet to define the high level objectives and design of the to-be system. IT is considered outside of this effort; their role is to accept and implement these plans, but not to participate in their creation.

This is a mistake. IT should certainly be included in discussions in which all stakeholders are meant to have representation.

First of all, there’s a real benefit in including IT contributors early in the process because it enables this important group to participate, understand, and own the overall objectives. Creating consensus is a major benefit of the successful software initiative, and achieving this benefit can start right away. Downstream in the process, detailed business analysis will result in software requirements that are long and complex, but the initial, high level plan is likely very simple. Enabling IT to understand the spirit of the effort makes an enormous difference in the interpretation of requirements, and therefore the quality of the end product.

Software development is an intensive, thorough process. It’s where the rubber meets the road: no amount of analysis prior to the start of development can prepare for the realities that will be uncovered during implementation. The job of the software team is to methodically step through business logic. This process naturally leads to detailed questions about states of the system that other stakeholders cannot possibly uncover, no matter how thorough their analysis. It’s natural that through this rigorous process, the software team will become extremely familiar with the real business cases, and all of their underlying detail. This knowledge and experience is invaluable to the steering team during high level planning and objective setting; it is a foundation to build the scaffolding of any new effort.

IT possesses unique knowledge of the technology; they also have unique knowledge of the business domain. In fact, no other group has quite the depth of experience or perspective as the IT group does about the functions of the business.

And then, there is the implementation curve itself. A rule inside development is that 80% of the effort of the implementation will occur during the last 20% of the project. In my experience, half again of that effort will occur during the last 5%. It’s only until the implementation reaches this level of progress that the real work is uncovered. There’s simply no way to simulate, analyze, or re-create this curve prior to beginning the implementation; it’s a reality that is difficult to predict and must be experienced. The software team that endures this kind of rigor, day in and day out, will gain an intensive understanding of the enterprise business domain. This knowledge is exceptionally valuable to the business. It’s a finely distilled result of the effort of the implementation, and it is of direct benefit to future efforts that create value through IT.

The IT team is composed of very smart people. Software itself can be complicated. Enterprise software can be more, or less, complicated to implement than other forms of software, but it is certainly complex in it’s own right. Enterprise software is the merger of the technical domain, in which many useful and mainstream technologies exist and must be well understood to be used correctly, and the business domain- specifically, how technologies can be leveraged to solve business problems. This means that enterprise developers have a lot to master. It also means that they’re good at a lot of things, and can potentially fill many roles within the team. Certainly this combination of intelligence and mastery should be included by the steering committee making decisions for the future of an enterprise software system.

The software development team is a valuable component of the enterprise. They should be included as a key stakeholder during any decision about the future of an enterprise development program, and the business value that can be generated through software.

Posted in Uncategorized