‘Projects, like diamonds, are forever’
‘It doesn’t turn out to be what you had wanted’
‘Systems are so inflexible, even a minor change is two months away’
‘IT guys don’t stick around’
With these kinds of perceptions and assessments of end-users, it is clearly thumbs down for custom software development projects. Software continues to be custom developed at least where a) Stable, good-fit and cost-effective ready solutions have not yet emerged. b) If the applications are in some special niches. Or c) Currently available solutions do not leverage newer technologies that bring significant benefits. All of these still add up to substantial action in custom software development. Hence, the pressure on IT professionals to constantly hone up SDLC skills and practices to do better than ever before in the face of all these negative assessments and perceptions.
In this piece and others to follow, we will take up some simple incremental ways of perceptibly adding significant value, which would not appreciably alter the prevailing basics.
Any application provides its user with some capabilities relevant to business. When a user exercises a capability, he derives definite value resulting out of a transaction (a transaction is actually an exchange of values). The capability is delivered by the application by initiating a corresponding main service process which in turn invokes or works in tandem with other services to get the job done. Thus an e-store gives a shopper the capability to shop on the net. The direct tangible value he derives is the goods ordered and delivered at home. The balancing value that the store derives out of the transaction is the payment user makes for his purchase.
Here are some easy opportunities for enhancing value:
Let us look little more closely at the process of detailing out the requirement in providing a capability to the user. The requirement could be captured formally as a use-case or it could be by way descriptive text. The discussion following assumes the way of use-cases without any loss of generality.
While the primary user or beneficiary of a use-case is quite evident, it is not so with secondary users. With some dogged drilling down, a number of secondary users may be uncovered who could possibly derive some value out of this capability. The secondary users may not even have a direct role in the use-case; they may merely be recipients of alerts. For instance, when a new employee joins, an alert could be generated to various other functions and systems to induct him. The infrastructure function may be alerted to provision him with computing resources. The administration function may be alerted to arrange for security badges, etc. The secondary users exercise their own capabilities to get their jobs done, but the alerts are useful to ensure the ball is not dropped especially at process breaks, ubiquitous in organizations. And all of this is realized with only a little more of digging.
Practice: Examine a use-case carefully to uncover more secondary users who could possibly derive value. It could even be in the form of alerts.
The same principle may also be applied to the application as a whole, seen as providing a collection of capabilities to different users. A quick view of these capabilities sorted by their main beneficiaries or users will usually show a skew. This immediately prompts a question: Is the skew intended? Example: The application administrator, by design, has capabilities limited to administration of the application. Or, it could show up an opportunity for empowering some of those cinderellas with more capabilities in this application? And the effort involved in realizing these additional capabilities may only be incremental. This may even trigger a larger and beneficial debate on the user’s role as envisaged now in the oranization and its possible enrichment!
Practice: Construct a view of capabilities arranged by users. Examine this view to spot opportunities for strengthening user empowerment (righting the skew).
More to follow…