« Risk Management - A Short Definition
Risk Management - Risk Profiles »

Enhancing Value in Project Delivery

July 25, 2008 | Author: PM Hut | Filed under: Project Management Best Practices, Requirements Management

Enhancing Value in Project Delivery
By K Raghunathan

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 potentially 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).

K Raghunathan is an IT professional with wide ranging interests in software definition and production, particularly passionate about processes of requirements gathering, architecting and designing software systems. His extensive and continued involvement in projects and quality processes gives him the practical insights that he shares on various forums. Working as Technical Advisor to Blue Star Infotech and as CIO of Blue Star Ltd. he sees himself as a strong spoke-person for users within IT and in simplifying technology induction. Raghunathan runs a professional blog: KRag’s Weblog, and can be contacted by email through kraghu@bsil.com.

Blue Star Infotech (www.bsil.com) specializes in providing product engineering services on Microsoft and Java technologies with a significant presence in Healthcare and Travel and Hospitality verticals. It is also engaged in rolling out enterprise solutions from industry leaders.

Share this article:
  • Digg
  • del.icio.us
  • Facebook
  • Google
  • blogmarks
  • LinkedIn
  • Reddit
  • StumbleUpon
  • TwitThis
  • Yahoo! Buzz

Related Articles

This entry was posted on Friday, July 25th, 2008 and is filed under Project Management Best Practices, Requirements Management. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

No comments yet.

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories