How to enjoy Christmas (a book which contains everything you have every wanted to know about making the most of Christmas, from wrapping gifts without sticky tape, to what food to present at the table and the very best of traditional Christmas games)

and

How to look after wooden flooring (including what are the different types and shades of wood you can use and how to maintain your precious investment)

and

How to maintain terracotta floor tiles (similar to above but related to all the different types of terracotta tiles)

and

How to kids occupied on car, train, plane journeys (self explanatory – its a parent’s most useful bible for disruptive and attention seeking terrors)

and

Ebook readers – here to stay?

I shall post links to the websites shortly where you can purchase them or just review chapters

• communicate a vision of what the business stands for and where you want it to be and where you want it to be;
• communicate values and priorities across the organisation;
• ensure the work is challenging, with a variety of tasks;
• establish a friendly, collaborative work environment;
• consider more flexible working practices;
• delegate tasks and allow others to take responsibility;

• involving them in decision-making;
• providing personal encouragement;
• recognising and rewarding good performance;
• helping to build their confidence to use their own initiative;
• inspiring them with a vision for success;
• ensuring good two-way communication;

• Demonstrating trust – don’t micro-manage. Trust staff to get the job done;
• Showing respect – listen to and act upon what your employees tell you;
• Giving encouragement – if someone’s standards fall short, don’t criticise, but find out what the problem is and try to get them back on track;
• Valuing diversity – what works for motivating one person, may not work for another;
• Rewarding good performance – set clear objectives and celebrate employee achievement;

PROJECT X

> Management

– meetings
– plans
– timesheets

> System

– Implementation
-== Training
-=== training docs
-== Source
-== Tests
-=== test cases
-=== test results
-=== UAT
– Requirements
-== Requirement Documents
-== User Stories

How you supply this information is entirely down to how your manager wishes to read it.  You might be lucky enough to have a line manager who just wants the bare facts, or you might have a manager who wants all the details – it depends.

Project Monthly Report Contains

• brief description of project;
• project programme;
• achievements;
• risk;
• quality;
• actions for next month;
• key decisions required;
• spend and cost analysis; (might have to include forecasts)
• key issues;
• overall status;

There is nothing to be afraid of in the completion of the monthly report, it should just contain the key facts.  Don’t make it long winded, keep to the facts, concise, accurate …

I suggest using a matrix, easier to read and format.

Your matrix will include the following:

• receiving name;
• receiving role;
• summary of information required (the project artefact);
• information provider/supplier;
• frequency;
• delivery method (security may need to be considered depending on your project);
• format (PDF, MS Word, URL etc.)

Make sure all your stakeholders are in agreement to receive this information, it’s most embarrassing when you send someone information out of the blue and they don’t know why they have received it and what they should do with it.  Make sure that the frequency, content and method of delivery is agreed with all parties.  Use common standards, define the language you will use.  Plan it into your Plan.

Do not use the communication plan to send actual project details.

Remember it also depends on the size of your project, so you may include your ‘communication plan’ into the project approach or project brief artefacts – it just depends!

• financials > estimated costs (development costs, resource costs, etc.)
• risks (and I would say issues too since you are highlighting risks, I feel they go hand in hand, and issues may have already occurred so its worth noting them)
• benefits (cost savings, quality, ROI, other business benefits etc.)

The ‘Project Board’, ‘Steering Committee’, ‘Project Sponsor Board’, whatever it’s called in your organisation will monitor the viability of your project against your BC – so keep it up to date!

Business Case Contents

• Reasons for the commencement of your project:
  The reasons for the project should be stated, clearly and concisely to your readership.  Ask yourself “why this project being performed?”.  If you are getting stuck at this stage then it indicates that further thinking and questioning is required (to your project sponsor, your project board and maybe directly with your customers) before going to the next steps.
• Costs (all associated costs):
  Derived from your existing project plan – based on the resources needed (developers, vendors, suppliers, hardware, additional software to purchase, licences, programmers, administrators etc) and timescales. It should be possible to come up with a quantifiable estimate from discussions with the suppliers and developers.  It’s not a figure that you pluck out of the sky, its a justifiable ‘budget’ based on tangible costs and time. Ongoing operational costs, over a given time after project closure, might also be included to give your project sponsor additional cost implications, especially relevant if a third party is going to support the new system (I am mainly talking about IT at this stage).   It maybe helpful to breakdown the costs further depending on the project (e.g. design costs, additional building/premises costs,  training etc.)
• Benefits – Tangible & Intangible
  This could add huge muscle behind your project if you can express the benefits of the BC to your audience, and remember your audience is not just the IT section/department!  Sometimes the softer potential benefits are skimmed over in this subject, so let’s take a more meaningful approach.  Express the benefits that will be reached against what is the current situation now – easy?  Some of your benefits may be measurable or ‘tangible’ in monetary terms (cost savings here and there, reducing hardware spend or costs, increased revenues, more money in the organisations accounts, following regulations or legislation (and not being penalised) etc.). Others will be ‘intangible’.

  Let me deviate for a short time and let’s take a closer look at the intangibles because they can sometimes be more important to the business than an IT director cares to think about at this stage, but equally needs to be documented so that your project can be JUSTIFIED – that is the bottom line after all.  Intangible benefits certainly deserve more respect than they are given as they form part of the business’s worth, and include such items as ‘brand image’ or  ’reputation’, ‘market share’ etc. yet decision makers have not accepted this financial reality in its entirety.  Why?  Not quite sure, but I will hazard a guess at the lack of hard numbers for the ROI and frankly how do you quantify ‘brand image’?  If organisations put as much effort into identifying the ‘intangible’ benefits, do you think their strategic goals would improve, or their market share would increase or their competitive streak would show an increased advantage?  Maybe its time to sharpen the ideology and refocus project strategies and maybe its time project managers start asking these questions from the business owners – it would be a good starting point for a transparent round table information gathering, not hiding it under the table out of sight.  So should project managers be describing intangibles as tangibles?  A core skill of senior managers is the ability to make the right decisions in the face of less than factual (intangible) information.  Yes there is an element of risk involved, but given some hard facts, doesn’t that risk reduce, and doesn’t this transparency we are talking about increase the stakeholder confidence in management.

An example: a newly bought or developed ITSM (Service Management) system/tool will benefit the IT Service Desk by reducing resource times on each incident, improving customer service & its perception, problem resolution is forwarded to specialist groups rather than clogging up resources on 1st line support, improvement in process management is achieved, service desk managers can evaluate where further staff resources are required or can be drawn back to reduce costs etc.

• Risks (keep a Risk Log or Register)
  (ID, raised by, date, description, probability, impact, score, actions, owner, escalation, risk reference, open/closed)
• Timescales (summarised from your Project Plan > Gantt chart > MS Project)
• Investment Appraisal
• Assumptions & Evaluations

The BC is derived from the Project Brief (or Mandate), the Project Plan and most importantly the customer, the end user who benefits from the project within your organisation (project sponsor).

Let’s take a look at what information is required in a Project Manager’s ‘Business Case’.

Honestly, it doesn’t have to be that hard – so don’t let it scare you into a quivering wreck in the corner of the office.

Let’s begin by looking at what you need to initially focus on to get the ball rolling in your organisation.  Let me also state that you will need at the minimum two full-time resources (permanent or contractual) for this if you were looking at implementing SLM in a medium sized nationally spread organisation and you wanted to have 1000 services catalogued and contractually agreed inside your ITSM tool/system with a time duration of one year (all dependent on the complexity of the organisation of course).  I’m trying not to sound biased here when I say that it take a special character of person to fulfil this role to it most effective means.  You should consider candidates who have the following skillsets for this role: time management, attention to detail, business analysis skills, documentation writer, confident, outgoing, pleasant, friendly, persistent, meeting organiser/chair person, a good presenter, articulate, concise, service management experience with Service Level Management, Service Catalogue and Asset Management, Configuration Management experience are just some of a list of skills you can begin to look for in your resources.

Challenging Times

It is true that there are still many IT managers and directors out there in many organisations who measure the effectiveness of their organisations by looking at the hardware and software components.  Think how limiting that already sounds!  ’Measuring effectiveness by looking at our hardware and software‘ – excuse me but where do the users come into play – don’t we care about them anymore?

The Accountants on floor 3 need to have SAP availability 100% 24/7 from 07:00hrs to 18:00hrs Monday to Saturday (incase one of them remote accesses the database on a Saturday!)  Doesn’t that sound familiar?  Sure we can have SAP up and running 24/7 6 days a week, but SAP operates on an infrastructure of other services like networks, routers, servers, databases, firewalls, backbones, SANs, LANs, WANs …. now the head is spinning.  So even if the IT manager could have SAP operationally available 100% of the time, in reality it might only be available 99.98% of the time because there are other dependencies.

Now we know where we stand, let’s try and understand SLM in more detail.

SLM is a disciplined, proactive methodology using processes and procedures to ensure adequate levels of services are delivered to all IT users (customers) aligned with business priorities and wait for it COST.  IT has to understand the ‘relative’ priority of each of the services it provides and the business importance of each of those services, whether they are delivered internally or externally to an organisation, whether they are delivered by the IT department or are outsourced by the IT via a 3rd party vendor.

Service levels are defined in terms of availability; responsiveness; integrity & security.  The SAP system is not only used by the Accounts department but also the HR department so all services must relate directly to the end user (the customer).  So how is all this defined?  When you start a new job, you have a ‘contract‘ it defines what your daily duties will be, how you should perform, what your remits will be, and so there is a statement of what the company will do for you, your salary, pension and benefits, your working times etc … so it is very similar to the agreements between the IT department and the end users/departments/3rd parties etc.  It is most likely to also include some clauses regarding compensation and warranties.

Consider this: one has the choice of 2 vendors who deliver a service to IT.  The IT manager receives both bids, one with a comprehensive SLA and the other with a few mentions of ‘promises’.  The astute IT manager will of course choose the bidder with the comprehensive SLA because this vendor is saying they can offer 100% reliability and include penalty clauses if they fail to deliver – exactly what the IT manager is looking for.  When you purchase a new car from a dealer, don’t you ask for some sort of warranty so that if the car goes wrong then you have some course of recompense – and you have more legal rights with this warranty contract too.  When you purchase a car from a private owner, its really sold ‘as seen’ – you see it, you drive it, you poke around, you check the log book, but there is no warranty that the private seller can ‘sell’ you.  If you are a cautious person you would buy a car from the car dealership, if you were a risk taker and you know you might be able to fix the car up yourself, then you would go to private sellers.

More to come shortly …

NOT TECHNICAL DECISIONS OR TECHNOLOGY STRATEGIES

EA is the key enabler for business flexibility and integration of well planned processes and orientation of technologies to services.

SOA (Service Oriented Architecture) is defined as a framework from integrating business processes and supporting technology infrastructure as:

LOOSELY COUPLED
SECURE
STANDARDISED FOR RE-USE
FLEXIBLE TO CHANGES IN BUSINESS PRIORITIES

SOA is deployed on a platform of web services at this moment in tme. Web service platforms and related technologies include:

.NET
JAVA
SOAP
UDDI
WSDL
XML

This makes integration with other applications very flexible. Cool, because we all like flexibility.

So we move away from complex departmental applications with complex and multiple processes to a streamlined organisation-wide process integration model, which benefits from agility, flexibility and efficiency, as well as future integrated applications from a SOA.

Benefits of a SOE (Service Oriented Enterprise) lie in mixing and matching services in other ‘on-demand’ solutions.

From the inception of a project, governance decides the priority of services for release throughout the organisation. This is a critical step as it ensures consistency and interoperarability among the services and ensures that the technology strategy of the organisation remains synchronised with the business strategy and doesn’t veer off course. Do you think that this will assist in the re-use of services? Sounds like it.

Using the Agile project methodology ensures that there is some flexibility for changes to the process requirements from external sources, internal sources or maybe regulatory requirements. Delivering on releases of services in an incremental and interative manner ensures consistency throughout the lifecycle (top-down in design from business management models AND bottom-up in design from ops and platform technologies).

Faster releases of services
Flexiblity to changes

Demystifying IT Governance

Definition of IT governance “specifying the decision rights and accountability framework to encourage desirable behaviour in using IT”

IT governance is not about making specific IT decisions— management does that—but rather determines who systematically makes and contributes to those decisions.

For example:
• Governance determines who holds the decision rights for how much the enterprise invests in IT.
• Management determines the actual amount of money invested in a given year and the areas in which the money is invested.
• Senior management team designs IT decision rights and accountabilities to encourage the enterprise’s desirable behaviours.
• If desirable behaviour involves independent and entrepreneurial business units, IT investment decisions will be primarily with the business unit heads.

Good governance design allows enterprises to deliver superior results on their IT investments.

Governance of the key assets occurs via a large number of organisational mechanisms (for example, structures, processes, committee, procedures, and audits).

The key assets are:

• Human assets
• Financial assets
• Physical assets
• IP assets
• Information and IT assets
• Relationship assets

Effective IT governance must address three questions:

1. What decisions must be made to ensure effective management and use of IT?

2. Who should make these decisions?

3. How will these decisions be made and monitored?

What decisions must be made and who should make them?

Think of the Governance Arrangements Matrix.

The column heading of the Governance Arrangements Matrix lists 5 inter-related decisions:

• IT principles
• IT architecture
• SOA architecture
• IT infrastructure
• Business application needs
• IT investment and prioritisation
• IT governance policies, processes, mechanisms, tools & metrics

Each archetype identifies the type of people involved in making a decision:

• Business monarchy
• IT monarchy
• Feudal
• Federal
• IT duopoly
• Anarchy

The ‘Governance Arrangements Matri’x (GAM) maps the types of decisions and the archetypes for making the decisions, the third question “how these decisions will be made and monitored” requires design and implementation of governance mechanisms, such as committees, roles, and formal processes.

Infrastructure must balance the dual needs of cost effectiveness in meeting current business requirements and the flexibility to support future business needs.

Governance also facilitates learning by formalising exception processes.

Renegade decisions result from poorly designed, poorly communicated governance arrangements that are not aligned with management incentives.

Carefully designed IT governance provides a clear, transparent IT decision-making process that leads to consistent behaviour linked back to the senior management vision while empowering everyone’s creativity.

Centralised and standardised IT environments ensure reliability, cost effectiveness, consistent customer service.

IT governance structures create strategic control at the top of the firm while empowering decision making at multiple organisational levels.

Governance design and analysis requires stepping back from day-to-day decision making, taking Einstein’s advice and focusing on identifying the fundamental decisions to be made and who is best positioned to make them.

• What decisions must be made?
• Who should make these decisions?
• How will we make and monitor these decisions?

Who is making each of these decisions in my enterprise, and how qualified are they to do so? Also ask, How are we measuring and monitoring decision-making performance and business value?

Every enterprise must address 5 inter-related IT decisions:

IT principles
IT architecture
IT infrastructure
Business application needs
IT investment and prioritisation

The principles reflect the importance of knowledge-sharing across the enterprise, and they have led to increased awareness of how business value is achieved from IT.

The IT architecture is the organising logic for data, applications, and infrastructure, captured in a set of policies, relationships, and technical choices to achieve desired business and technical standardisation and integration.

Enterprises need an organising logic for data, applications, and infrastructure because integration and standardisation shape IT capabilities.

Technical standardisation facilitates common objectives such as cost-effective processing, negotiated vendor agreements, and enterprise wide security.

The enterprise architecture guides new application development by explaining how IT will deliver on the firm’s IT principles.

Enterprise architectures capture the organising logic in technical choices and policies.

IT infrastructure is the foundation of planned IT capability available throughout the business as shared and reliable services and used by multiple applications.

An increasing number of enterprises have an additional layer of standard applications used by all business units. We refer to these shared and standard applications as infrastructure applications.

Getting infrastructure right means providing cost-effective services that position the enterprise for rapid adoption of new business applications.

Identification of business needs for IT applications often has two conflicting objectives – creativity and discipline.

The IT investment decision is often the most visible and controversial of the key IT decisions.

IT investment decisions address three dilemmas:
(a) how much to spend
(b) what to spend it on
(c) how to reconcile the needs of different constituencies

Enterprises implement their governance arrangements through a set of governance mechanisms—structures, processes, and communications. Well-designed, well-understood, and transparent mechanisms promote desirable IT behaviours.

Why? To communicate and understand at the same level. Why? To avoid misconceptions!

CLASS DIAGRAMS

- capture static relationships of software;
- capture the physical structure of a system;
- understand what classes reference other classes;
- understand which class ‘owns’ another class;
- a CLASS represents a group that has common states and behaviours
- the RELATIONSHIPS include: dependencies, associations, aggregations, compositions, generalisations, associated classes and associated qualifiers.

class diagram example

USE-CASE DIAGRAMS

- capture and define functional requirements;
- a user story and a use case describe ONE THING ONLY that the software needs to do.

use-case example

ACTIVITY DIAGRAMS

- the “how” does something to something else;
- derived from workflows and flowcharts, because they look very similar;
- defines the behaviour of the model being described.

activity diagram example

SEQUENCE DIAGRAMS

- defines object interaction at runtime to bring software functionality to life in an executed order/sequence;
- used for dynamic modelling.

sequence diagram example

USE-CASE NARRATIVES (non-diagram, text only)

- used to describe the use-case in more narrative terms;
- contains: use case name, iteration, summary, pre-conditions, triggers, course of events; alternate paths; post-condition; business rules; notes; author & date.

The DS domain focuses on the delivery aspects of the information technology. It covers areas such as the execution of the applications within the IT system and its results, as well as, the support processes that enable the effective and efficient execution of these IT systems. These support processes include security issues and training.

(3) Deliver & Support (DS)

PROCESSES

DS1 Define and Manage Service Levels
DS2 Manage Third-party Services
DS3 Manage Performance and Capacity
DS4 Ensure Continuous Service
DS5 Ensure Systems Security
DS6 Identify and Allocate Costs
DS7 Educate and Train Users
DS8 Manage Service Desk and Incidents
DS9 Manage the Configuration
DS10 Manage Problems
DS11 Manage Data
DS12 Manage the Physical Environment
DS13 Manage Operations

Let’s now approach it in more detail and include other processes and activities that are involved.

(1) Business Requirements, External Requirements, PO and AI domain are important inputs into the strategic cluster or ‘heart’ as I shall refer to it here.

(2) Within the ‘heart’ of this domain lies a few interesting clusters: The Service Level Cluster made up of processes DS1 (which is the key process here) and DS2. Related to the DS1 & DS2 (define & manage service levels AND manage 3rd party services) is the related DS6 ‘identify and allocate costs’ because we want to know about the financial implications.

(3) Feed down to the next important cluster – The Operations Cluster (DS11, DS12 & DS13 – managing data, managing the operational environment and managing operations respectively)

(4) As side ‘organs’ to the ‘heart’ we have the delivery cluster, or as I will refer to as the ‘brains’, which include the following processes (DS3 through to DS7), or in plain English, maaging or ensuring the performance and capacity, ITSCM (a reference to ITIL there), security, education and training.

(5) On the other side assisting the ‘heart’ we have the usual suspects for the general resources cluster, or ‘organs’, PO8, PO9, PO10 & ME1-4 (managing quality, IT risk and projects and all that monitoring and evalutation stuff that we shall cover shortly). You see you always have to keep an eye on the IT risks as a matter of principle, probably best to have a Risk Register.

(6) Before we come to the outputs of this domain, let’s take a look at two further processes that have their roots in ITIL, namely those of DS8 (Managing Service Desk and Incidents) which feed out to DS10 (Managing Problems).

(7) So what are the outputs of DS. We have AI and PO as outputs from DS.

SUMMARY

Inputs = Requirements, PO and AI.

Outputs = AI and PO.

Acitivities of the ‘heart’ = SLM Cluster, a bit of financial management, Operational Cluster, Service Desk, Incident and Problem Management.

Activities of the ‘organs’ = Quality, IT risks, projects & lots of monitoring and evaluation.

Activities of the ‘brain’ = Performance and Capacity management, Continuity management, security management, education and training management.