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!

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

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.

August 11, 2008

RACI tables in ITIL, in projects, in life!

Posted in ITSM, Project Management, RACI matrix tagged , , , , , at 4:45 pm by Molly

Open your Service Transition v3 books, turn to page 166 and you see table 5.3 “example of RACI matrix for managing change“.

Notice how the change enabler can be either a process owner or a service owner. This table doesn’t make it entirely clear to the reader at first sight that these two roles are considerably different. Therefore, when I created this table, I duplicated this Change Enabler to be either a process owner or a service owner with their own defined rules.

RACI = Responsible, Accountable, Consulted and Informed.

Referenced in Service Design & Continual Service Improvement.  Its a model used to help define roles and responsibilities.

Responsible:  the person or people responsible for getting the job done.
Accountable: the person who is accountable for each task (can only be one person).
Consulted: The people who are consulted and whose opinions are sought.
Informed: the people that are kept up-to-date on progress.

For example:-   The PROCESS OWNER is responsible for their proccesses and the SERVICE OWNER is accountable for a specific service.

V3 exam question:

A Service Owner is responsible for which of the following?

  1. Continual Improvement of the service
  2. Designing and documenting a service
  3. Carrying out the Service Operations activities needed to support a service
  4. Producing a Balanced Scorecard showing the overall status of all services

Can I use RACI Matrices for other applications ?

I had an interesting conversation with someone recently, the conclusion of that discussion, prompted me to edit this post and it all centred around the RACI table.  A somewhat bold statement was made during this conversation, and it goes something like this, “.. you can use RACI tables in everyday situations”.   It got my head in a spin, because I wanted to come up with some sort of smart retort that RACI tables or matrices could only be used in service management, but today I found blurting out the words “let me create a RACI table for that”, and it wasn’t even related to anything ITIL, it was concerning additional resources for a project.

Stay with me now, don’t loss track of what we are talking about, because I think I’ve also just hit the nail on the head with this one, and am becoming to see myself as a the number one fan of RACI tables.  Wouldn’t it be dandy to have a RACI table which depicts your project resources, either those directly in your control and those that you liaise with closely or whom provide you with information (indirectly or directly); then the tasks or actions down one side, then you can ‘control’ through your RACI table who has the responsibility to source this & that, who is accountable (say to manage the information i.e. make sure of its accuracy, its completeness etc.), who is consulted for information or for project updates (information inputs and outputs etc.), and who is kept informed on a daily, weekly, bi-weekly running period (sounds familiar?).

What also intrigues me is the fact that you don’t even have to manage this table once it is 100% accurate, unlike the project plan, but a word of warning to you, don’t use the RACI table to ‘replace’ the project plan, no way can it be used to convey milestone dates or other such deliverables.  What the RACI table I just mentioned will give you is the holistic view of ‘people’ and as project managers we need to constantly be fully aware of what is communicated around us with regards to personnel.  Loss sight of resources, and they will be pinched under your nose without you knowing about it (how many times has that happened to you?).  Loss sight of their involvement in your project and your project may loss its focus and milestones will start to slip like a mudslide on a rainy day (look how devastating they can be).

Also, don’t ignore the RACI table totally, but don’t think you need to update it on a daily basis either, its a tool, another tool you can carry with you on your project manager toolbelt each day.

I’m dying to find more uses for RACI tables, and when I come across them I shall update this page and share those experiences.  Am sure there are hundreds of applications where I can use it.  So start using it yourself, and if this inspires you, jot me down a quick comment on the page and share your experiences, as I would love to hear them all.