We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

IT Directions

Keith Harrison-Broninski

The new process modelling - a typical Activity

Vote 0 Votes
In the last post I explained why HIM Activities provide a way to capture, maintain and re-use knowledge gained during execution of work items.  Here I'll give an example to illustrate.

Consider a project to set up a new government organization.  In HIM terms, there will be a Stage with the goal of setting up premises with associated physical network and computing equipment.  Let's suppose that the number of staff is large enough that creation of this IT infrastructure will be outsourced via request for tender.

A key Activity in the Stage will be to gather requirements for the IT infrastructure, including details of the components required: illustrative usage scenarios, deployment types, benefit profiles, state changes, related service processes, service-level agreements, and so on.  These requirements will be used as input to a Request For Quotation (RFQ), so the key output from the Activity is text, appropriately formatted for use in a RFQ document.

However, the Activity will also produce a number of other outputs.  For example, gathering and analysis of the requirements will make use of a dedicated requirements management tool, to assist with completeness and consistency checking.  Hence the repository created via use of this tool is also an output of the Activity - it may not be directly used to create the RFQ, but represents valuable knowledge that may well be used by the supplier that wins the bid, both to set up the infrastructure initially and also for on-going maintenance.

A further, even more indirect, output of the Activity is the way in which it was carried out - in particular, the work that was done to select a requirements management tool.  This may involve, for example, a feature comparison using reports from analyst firms as well as a price comparison that required contacting vendors for quotes.  The selection of the tool may turn out to be quite a time-consuming and complex task in itself, so its outputs are certainly worth re-using on future occasions that staff of the organization need to gather requirements.  Even if their needs are different on other projects, it is bound to save them time if they can refer back to the outputs of this selection process.

In both cases, the value of the indirect outputs are enhanced immeasurably by their association with the requirements gathering Activity - without that, they are unlikely even to be found by the people that need them on a later date.  Especially as the organization grows, knowledge such as this will become buried in a vast network of documents and data - unless HIM processes are used as a route map to traverse the network.  HIM Plans provide a means to join up all work in an enterprise, from strategic decision-making at the very top, to low-level automated workflows at the grass roots.

In the next posts I'll look at resource and cost planning/monitoring using HIM processes.  In the meantime, if you would like to try HumanEdj, visit http://rolemodellers.com/get_started to register for an account on the demo Web instance.

Keith Harrison-Broninski cuts through the hype in his hands-on guide to where enterprise IT is really going

Keith Harrison-Broninski

Keith Harrison-Broninski is a researcher, writer, keynote speaker, software architect and consultant working at the forefront of the IT and business worlds.


 Subscribe in a reader

Recently Commented On

Monthly Archives