September 23, 2010

Ebooks pending publication

Posted in Ebooks tagged , , , , at 10:08 pm by Molly

I’m starting an ebook business, I’ve got 5 completed, very non-IT ebooks that I will soon be publishing them, so keep your eyes peeled for updated links.

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). Purchase the ebook at http://www.ice-cleaningexperts.co.uk/ebooks/

and

How to maintain terracotta floor tiles (similar to above but related to all the different types of terracotta tiles). Purchase the ebook at http://www.ice-cleaningexperts.co.uk/ebooks/

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

August 12, 2010

Writing a ‘Business Case’?

Posted in Deliverable Artefacts, Project Management tagged at 12:34 pm by Molly

A BC documents the justification for your project.  It is based on:

  • 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’.

November 12, 2008

Welcome

Posted in Welcome Note tagged at 4:45 pm by Molly

The Blogger

This blog hopefully will enlighten you in the specialist field of ITSM, IT Governance and respective frameworks and Project Management topics, as well as any other categories that come to mind during the course of writing.

I want to keep this blog as professional and focused on the subject matters described, therefore all comments go through an approval process before being published.  Feedback is most welcome here, and constructive criticism is never frowned upon, after all we learn from eachother and our own mistakes.

I hope you enjoy the blog …

May 16, 2012

Mould Removal

Posted in Uncategorized at 10:09 pm by Molly

Mould removal professionals can be found here, helping many distraught home owners and tenants in teh South East of England including Londoners.

http://www.ice-cleaningexperts.co.uk/mould/

August 12, 2010

Motivating your Project Team

Posted in Project Management tagged , , , at 1:47 pm by Molly

  • stop criticising upper management
  • keep giving feedback
  • lead from the front
  • hire motivated people
  • know your teams stregths
  • stop looking over your shoulder
  • 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;

What is a ‘Project File Structure’

Posted in Deliverable Artefacts, Project Management at 1:31 pm by Molly

You can use this project filing structure for Outlook or artefact storage.

PROJECT X

> Management

– meetings
— plans
— timesheets

> System

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

Writing a ‘Monthly Report’

Posted in Deliverable Artefacts, Project Management tagged , at 1:19 pm by Molly

There will be contracts where your senior line manager will request Project Monthly Reports from you.  An inevitable and sensible request in my opinion, a report that will comprise and gather details from other project artefacts you are currently updating.

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 …

Writing a ‘Communication Plan’

Posted in Deliverable Artefacts, Project Management tagged , , at 12:53 pm by Molly

It defines the means of communication and frequency of communication to all your stakeholders who are concerned or interested in your project.  It is a document that describes how you will inform all these people and what each person or group will receive, when (a timescale > weekly, daily, fortnightly, monthly, quarterly …).

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!

August 3, 2010

Starting with Service Level Management

Posted in Service Level Management at 3:34 pm by Molly

Service Level Management is one of those processes that some organisations hate to focus on because of the hard work that it entails.  It’s true though, it involves a cost element and maybe a few resources if you were to outsource this implementation, and so it is that it is usually left as a last step in any ITIL improvement or implementation project.

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 …

June 3, 2009

EA, SOA, SOE, Governance etc.

Posted in Uncategorized at 12:39 pm by Molly

EA (Enterprise Architecture) of services is based on business decisions or the business strategy

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.

Understanding the harmonisation

May 15, 2009

Spend 5 minutes understanding 4 UML diagrams before it’s too late!

Posted in Project Management tagged at 2:08 pm by Molly

UML – Unified Modelling Language

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

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

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

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

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.

Next page

Follow

Get every new post delivered to your Inbox.