Software as a Business Process? An ERP for Software Development?

I have been involved in many systems implementations projects, and its only really in last couple of years that I have come to appreciate that software implementations and development projects are beginning to be structured like any other business process.
And why? What do you mean you ask?

Let's take a closer look. Most of us in the industry look at processes day in and day out, as its part of the business world we operate in. The business we work for, whether a small to medium enterprise (SME) or a large multinational all have processes.

The most simple and wildly controlled of processes that businesses have are to do with money. Businesses live and die by the fact they can sell products (whether services, widgets or even software) and receive money for doing so. If we look at  Wiki's defintion of a process, we can see it's a fairly elementary component of the work we do.

Wiki's Definition: (Wiki Links)
A business process or business method is a collection of related, structured activities or tasks that produce a specific service or product (serve a particular goal) for a particular customer or customers. It often can be visualized with a flowchart as a sequence of activities.

So why has it always been so hard for software development projects to deliver on time and to budget? I think its because we do not do enough of standardising the processes related to our projects. Sure, we have project methodologies and analysis frameworks, but at the end of the day the projects we undertake always have the same common components and will therefore always fall into this simple definition.

My challenge to you therefore, is to look at ways we can better compartmentalise our systems projects and analyse them in the same way we look at the traditional business processes.

Software as a business process:

Let's go back the money process I outlined earlier on. Assume I am a company that has received an order for a service from another company, this would be the main process:

1. Raise a sales order
2. Deliver the service
3. Raise a good received note
4. Invoice the customer
5. Receive payment,
6. Complete transaction (match the sales order to the GRN to the invoice)

Store all the records in the companies ERP (Enterprise Resource Planning, think SAP) system and you're done.

Simple? Now in order to control my sales order process, I run reports to help me understand if someone does not pay on time..normally called the Aged Debtor report...this lists all those companies that have not paid me within the agreed period, so I have enough information to brow beat them till they pay up.

Why can't we apply this to software development? for example, assume I am a project that is delivering business systems enhancement requests to the main line of business:

1. Raise an enhancement request
2. Create the enhancement
3. Deliver the enhancement
4. 'Invoice the customer' ( recharge business by showing evidence via a traceability tree for example)
5. Receive payment (project charter or enhancement request closed)
5. Complete transaction

Store on the companies SDLC ERP system. We could then run a report highlighting which defects that are preventing delivery of the enhancement over the agreed time frame...the Aged Defect report...By doing this we are applying the same principles of business control to systems developments projects and  implementations. Processes and reports to control and manage the outcome, that's the benefit. We can also then start to compare this data across projects and start to lift the lid on the causes of software delivery delays. Apples with apples?

There's the glitch...most IT and Busines Systems departments do not have an ERP system for software delivery. However, I think we now have an answer to this problem.

I have been truly impressed by IBM Rational's Jazz platform of late (and I am as big a cynic as any, especially as I work in software) . With the release of 3.0.1 version, I can now state with confidence that the ERP for software delivery has arrived with the CLM or Collaborative Lifecycle Management offering. Like ERP that has modules of capability (Sales, Purchasing Stock Control, etc), Jazz has modules of capability related to the SDLC (Planning, Requirements, Design, Quality etc)...the journey and the challenge is on...

To know a bit more, check out Jazz and CLM 2011 here:
IBM Rational Jazz

Can both Waterfall and Agile development be used at the same time?

Coming from an old school background and learning my trade as a Business Analyst straight after Uni, I remained unconvinced about ‘agile development’ for a long time. I only ever saw the best way of guaranteeing project success was by capturing the requirements up front, creating traceability to more detailed requirements and so on. 

Over the last 9 months, I have been gradually converted to the agile method of software development. I owe a large amount of this renewed thinking to one of my colleagues from the US who shall remain nameless (despite the constant hammering about it), but it was not all his doing. More and more of my clients have been asking about Waterfall v Agile and what this actually means?

Over the course of several engagements recently and learning more about the practical application of Agile for software development, I worked with a client that wanted to use both.

Waterfall and Agile? Argh..or Maybe?

Folly! Was my first thought but when I lifted the lid, I found that there can be a place for both on the same project. Case in point, my client was undertaking the initial requirements analysis using Waterfall but wanted to develop using Agile. So we worked it through…

They captured the Business Objectives (level 1), eliciting the High Level Requirements (level 2) and then decomposing these into Detailed Requirements (level 3) and creating traceability across the three levels. Now came flip time. We decided to create work items (tasks) from the Detailed Requirements and enter these onto the Agile Product Backlog (basically the list of things to develop). From here they prioritised some them into a Sprint (a collection of activities to develop in a set time frame)
 and completed the activities (including some testing) to deliver working code at the end of the Sprint. Rinse and repeat for subsequent Sprints and there you have it, Waterfall and Agile playing nicely together.

So far, as long as you have clear demarcation lines between the two methodologies (i.e. they cannot exist in the same project in the same phase), they can coexist peacefully with traceability maintained.

I will post an update in a few months to see how it all turned out. 

I recommend Kurt Solarte's article on baby steps to Agile and Scott Amber's blog on Disciplined Agile Delivery. These further expand further on Agile concepts.

Three baby steps towards Agile Requirements Management

Here is a great article from Kurt Solarte for those thinking about using Agile as framework for Requirements Management.

There has been some great debates and comments on this article so its worth a view. Link below:

Three baby steps

Andy's keen eye..

I thought it would be a good idea to show a more human / normal side to the team in IBM ANZ.

One of my colleagues, Andy Rutherford who is based over in our Perth office has a rather unique take on IBM Rational.

Rational for breakfast anyone?

This is cracking photo...who doesn't love toast, cereal, bacon, eggs, coffee and fruit?!
Chatting with Andy he told me this one was fairly easy to capture with some subtle lighting..not like the next one..just a....

...drop in the ocean..

This next shot was cleverly captured by a lot of trial, error and patience (something Andy has tonnes of: Error, trials and err..some patience too)..

He suspended a plastic bag full of water from a ladder right above a container, making a small hole in the bag to get a consistent drip.

Using a Rational poster, a bit of luck and  three hours he managed to get this little nugget.

If you like these..there are plenty more weird and wonderful shots to see.

Click here to see more of Andy's photos

Rational Jazz on the iPad..

For my first blog....

I was pondering whether I could justify the purchase of an iPad. Like most people these days, they already have a laptop and smart phone that can sync email and calendar appointments and work on the move.

Recent developments in IBMs Rational's Jazz technology (that supports the Software Delivery Lifecycle) meant the value of using an iPad in day to day life is increasing. With the 3.0.1 release of the software, I can now access the Requirements, Planning, Development and Testing capabilities through the Safari browser on my iPad, tidy!

Although technically not a supported browser yet, you can see from the pic that I can now review Test Plans, browse Requirements and look at Development tasks.