Following my previous blog post here on Business Continuity, I would like to continue today on the same theme, but this time moving to the concept of resilience. 

Resilience in the context of Business Continuity can be defined as a combination of the following:

• Not being vulnerable – is your infrastructure, processes and plans capable of responding to threats that you have not even thought about, the so called “Black Swan” events.
• Robustness – is your organisation able to withstand stresses, pressures, or changes in procedure or circumstance without failing?
• Redundancy – do you have fall back plans / systems / processes to keep the business running?  These redundant options may require the business to chop and change in the event of the disaster …
• Adaptability and Agility - is the organisation agile enough to adjust to the changes imposed by the above?

Resilience is a property of not an activity.  That is to say it is what your organisation is that makes it resilient, not what it does.  Therefore resilience is a function of the People, Processes, Technology and Partners.  Moreover, resilience is determined by what your organisation is capable of doing, rather than the number of plans and documents you have.  Practice and rehearsals are much valuable to developing resilience than the plan artefacts, which reinforces the points made about BCP above. Resilience can be developed in an organisation, but it is difficult to measure.  However the level of resilience in an organisation can be observed during and after an incident. 

As with BCP, building resilience is a journey, not a destination.  As your organisation continues to evolve, so must the business continue to think about ways to ensure it remains resilient.

For further information on resilience, business continuity and disaster recovery, I would recommend reading Ken Simpson’s blog here.

The topic of the last PicNet User Group meeting was on Business Continuity and Resilience.  The discussion in this meeting revolved around the importance of business involvement and eventual business ownership in a successful BCP project and how to develop resilience in an organisation.  It is from these discussions I would like to share some of the thoughts on this subject.

All too often the terms Disaster Recovery and Business Continuity are (incorrectly) considered to describe the same thing, that is, the recovery of IT system after a disastrous event.  This has lead to a trend for the responsibility of creating and maintaining a Business Continuity Plan to be left to IT.  However, Disaster Recovery (DR) should not be confused with Business Continuity, for which DR is only a subset dealing primary with IT.  Business Continuity Planning (BCP) must include areas of business, not just the IT functions.

The experience of producing DR Plans puts an organisation’s IT department in good a position to enable and facilitate the BCP process.  However for BCP to have any chance of success, it is imperative that all functional parts of the business take an active part in the development of the Business Continuity plan.  Furthermore, long term success is dependent on the business taking ownership of the plan once it has been produced and dedicate the required resources in plan maintenance to keep it up to date.  One our customer has had direct experience of this.  Several years ago, this customer’s IT department undertook a project to produce a Business Continuity Plan for the for the wider business.  However, the BCP process had not been sufficiently explained to the business, which resulted in a lack of resources from the various functional departments.  Without sufficient business involvement, the project inevitably failed.  In 2009, the IT department once again took the lead in producing a Business Continuity plan.  However this time around, the process and the requirements were first explained to the Managing Director and the various departmental directors.  It was made clear that for BCP to succeed, the business as a whole must be involved and resources made available.  Once the plan had been produced, the business must take ownership of the plan and ensure it is maintained and kept up to date.  With the boarder business onboard, this second BCP project was successful.

When it comes to BCP, often it is the process rather than the end artefact that is of the most value to an organisation.  The process of planning for business continuity stimulates thinking on processes, organisation, suppliers, customers etc and ways to keep the business operating if the proverbial “sh*t” was to “hit the fan”.  The process of testing the BC plan either reinforces these ideas or (if it is found that the processes detailed in the plan are no viable) forces new solutions to these problems to be found.  This is also true for the maintenance of the plan.  The maintenance process allows the business to increase their awareness of the BC plan and to re-examine their business to verify that the details of the plan reflect the needs of the current business.

For further reading, I would recommend reading Ken Simpson’s blog here. 

More to follow in my next blog entry on Resilience.

The majority of projects that I have managed have been software development projects. At PicNet we use an agile software development methodology.

We like the Agile approach because it allows us to get feedback from the business on the system in development at a very early stage, thus enabling us to fix business logic and usability issues early in the project lifecycle.

This reduces the possibility of costly late functional requirements changes and also facilitates more business involvement in the development of the system, which fosters a culture of system ownership in the business. Ever since I start project management I have been curious as to how software development methods such as Agile fit with into the larger picture of project management, in particular how do they relate to methodologies such as PRINCE2?

I recently attended a PRINCE2 course and it was established that software development methods such as Agile, RAD, waterfall etc fit into the delivery layer of the PRINCE2 method. As PRINCE2 is a universal project management methodology, it provides great detail for directing and managing a project, but is deliberate silent on the method for actual product delivery. Software development methods such as Agile compliment overarching project management methodologies such as PRINCE2 and in fact the DSDM-Atern agile software development methodology is fully compatible with PRINCE2. A white paper on DSDM-Atern and PRINCE2 can be found here.

We are still in the early stages of incorporating our agile software development approach with the PRINCE2 method, and I would be interested in hearing from people who have gone through the process already.

As the old adage goes – “Time is Money”.  This is especially true for those who provide professional services providers.  At PicNet, as well as fixed timed contracts we provide our customers with additional services on an “ad-hoc” basis.  The issue of recording how much time we spend on each customer has always been something we have always struggled with.  Traditionally, professional service providers such as accountants or lawyers have recorded their times on paper timesheets and then at the end of each day / week, their data entry staff would enter these timesheet into a central invoice / billing system.  However for small boutique service providers like ours, this is not economically feasible.  So how does one accurately and cheaply time and record the time spent on each customer and project?

For some time we had been using an internally developed timesheet system where our engineers and developers enter in the timer they have spent on each project.  However such systems are dependent on either: 

a)      staff updating the timesheet whenever they perform a billable task; or

b)      staff keeping a detailed paper record of billable tasks and updating their timesheets on a regular periodic basis.

Both of these dependencies have their inherent problems.  Staff may forget to update timesheets after each job (especially when there are a number of short jobs throughout a day).  The accuracy of timesheet record could be called into question if staff are performing a number of jobs in a day and job overlap each other.  Keeping a paper timesheet is an overhead intensive task as it requires the staff to in essence fill out their timesheets twice and is reliant on the discipline of your staff to capture all required information on paper.

It seems then we require some simple, fast and easy to use application that will track and record the time spent on various tasks, without the need for extensive setup or configuration to start using.  Ideally it will include:  

• A timing function to time the duration of each tasks with pause function to allow for inevitable interruptions
• Comments against each task to record some task details
• An easy to setup pre defined list of task categories
• A tasks history which can be queried at a later time (when updating the timesheets).

On a search of the internet, I found several professional Project Management and time sheeting packages included similar functionality.  I came across TaskTracker, a simple java applet.  However its lack of a task history and support for task comments made it of limited use. Task Timer seemed to be quite a fully featured project task management and timing application, however I found it to be overly complicated to setup and overkill for my simple requirements.  Then there was Good Timing, an alarm and task tracking and timing application, which could be adapted to suit our needs, but was yet not that exact right fit.  Finally having almost given up hope, I came across a Desktop Timer by Vertabase.  This desktop widget was easy to use, quick to setup and tick all my requirements.  To top it all off, it was free!  About the only down side was that Desktop Timer required Adobe Air to be installed.  We have been using Desktop Timer for about 2 months now and it has been invaluable in keeping an accurate record of time spent on various project and tasks, and most importantly allowing us to accurately bill our customers at the end of each month.

Has anyone else found a good application or system to help them solve their Time Sheeting conumdrums?

- David