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.


> 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!

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

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 …