Archive for October, 2009

Fundamental Elements of the PID document

Last post(How to write a (PID) Project Initiation Document) I’ve described what a PID was – it’s uses and why it is an essential part of any project. In this post I will note down some of the fundamental elements of the PID document. But please also note that the contents of a PID may vary from Project to Project – there are however some key elements:

Project Goals
Layout in simple terms the goals of the project – this should include reference to the rationale behind the goal – for example – a project goal could be to reduce the risk of legacy technology by introducing a new ERP system. Notice there is a difference between Goals/Objectives and Deliverables.

Deliverables
What will the project Deliver? – for example is the project to deliver a written report, is it delivering a new IT system, is it delivering training – there may be multiple deliverables that need to be documented – ensure that the deliverables are measurable, so it can be proved beyond reasonable doubt that tasks have been completed

Scope
What is the scope of the project – for example is the scope “implement IT solution for Australian user base”. Note this should clearly explain who the project will be done to and anything that is excluded.

Financial Business Case
The business case should contain details of the expected costs of the Project. The Business Case should also indicate any savings that may result from the project – some business cases take a multi-year approach (e.g. 5 years) looking at the long term impact of the financial commitment.

Project Roles and responsibilities
A clear part of the PID is clearly outlining the authorities within a project. The PID should outline the Project structure e.g. sponsor, steering team, project manager, Project team and their levels of responsibilities – you may even consider drawing up job descriptions for the people within the team. The PID should define the resource requirement for running the project – for example does the Project require a team of 10? If it does explain why.

Risks
Consider any risks that may effect the Project – their likelihood of their occurrence and their possible impact. Include mitigation against the risks that you’ve identified.

Assumptions/Constraints
Are there any assumptions or constraints that you need to make about the Project? for example an assumption of introducing a new IT system may make some assumptions about what applications the system may integrate with?

Project Controls
Project controls, help schedule and measure projects – think about whether the Project requires Key Performance Indicators?

Reporting framework
Consider what information channels will be required during the project – will a monthly summary report to the Project Sponsor suffice? Or will it need something else?

PID Sign off
At sign off it is important to assess the PID and ask if it adequately represents the Project – is possible ensure that the customer of the Project signs the document as part of its release.

Summary
Constructing a thorough project initiation document is a key part of starting a project. Ensuring that key elements of a project, such as it’s goals and business case, are well understood is imperative. A PID can be referenced throughout a project and serves as a valuable route map for the Project team. Whilst their contents may vary getting down what’s important to your project can be a really valuable activity.

Popularity: 2% [?]

How to Avoid Work Scope Creep in IT Projects?

Congratulations! You’ve just got a new project / client for an exciting project that is going to be fun and profitable. You carefully discuss the work with client and he / she  / company sends in a e-mail saying that they like to go with you. BANG! You are off and running!

The following week, you are happily working on this exciting project and an e-mail pops up. It is about your great new project / client…wanting to make a slight change to the project. Hmmm… Being the wonderful and oh-so-easy-to-work with consultant that you are, you agree, sent a reply to that mail, and get back to work. A couple of days later, again an e-mail pops up. It’s from your {AHEM} great new client again with a “few more ideas for changes.”

“Well, okay,” you agree, somewhat reluctantly, and sent a reply.  Now, you have to go back and revise some of your work to date and your original estimate no longer covers the scope of work. Your new and exciting project just officially became a stressful time suck that won’t be such a great moneymaker.

Yes, it’s the Dread Work Scope Creep. {B-horror film sound effects kick in here with a woman’s scream at seeing the monster}. Does this sound familiar? If you – like many consultants – aren’t managing the change process properly, the result will be: stress, long hours, inadequate compensation, missed deadlines, an unhappy client and finally an unhappy YOU.

I’m 100% sure that each and every project manager has gone through this situation at least once in their PM life. And also they don’t even want to remind that and they desperately looking for solution for this. Well, there is hope. Here are some tips to help you manage those “little” changes to keep them from growing into the monster project with no end in sight:

Create a Contract: Ever heard the expression  contracts keep friends? Well, it’s true. Your written agreement should describe what you doing for this specific project, what each party is responsible for (deliverables), and how much it will cost. Also, make sure to include a line that explains costs for additional services, revisions, meetings, and so on that are requested by the client and are outside the scope of the agreed-upon project. Both parties should sign this BEFORE the onset of the project.

Communicate Changes: When your client calls / email you asking for changes, make a note of the conversation. Then, write them down and e-mail them to your client. Make sure you are clear about how this affects the project budget and/or deadlines. If it is a new client, you may want to consider a follow-up call or e-mail to ensure they understand how their request will impact the project.

Don’t Over commit: Don’t say “yes” just because you are afraid to say “no.” (I have said yes several times simply because that I could not say no to client. But because of that I have had really bad experiences.)So, It is perfectly acceptable to tell your client “it won’t work.” Make sure to follow up with a valid explanation and tell them what you are willing to do. If your client doesn’t respect you, your abilities, and your time constraints, he or she is not a client you want to keep.

By managing your work change process effectively, you will avoid the Dreaded Work Scope Creep {Horror flick scream again}. This will help ensure your projects and client relationships are profitable, pleasant, and manageable.

Popularity: 7% [?]

How to write a (PID) Project Initiation Document

Hey Guys, I couldn’t write anything for couple of weeks. Actually was kind of busy with the office work. Again got some free time and thought of writing some stuff on IT Project management since I was doing those stuff as my new job profile. Anyway after thinking nearly for 1 hours time on what should write on this area suddenly flashed to my mind how much difficulty I’ve went through when I was given to write a PID (Project Initiation Document). So I thought of sharing my learning outcomes with you guys and also wanted to write it down in proper way since its always better for the future references. Please note that I collected information for this series of articles from the web and I’ve mixed it with my work experience.

A project initiation document is a reference document produced at the outset of a project. It contains a range of information pertaining to the project including it’s background, deliverables and ownership. One of the most comforting things to have as a Project Manager is a full awareness of the customer’s requirements, the deliverables and the knowledge that the project has strong foundations with both firm ownership and sound business case. Capturing and documenting key information such as this before a Project kicks off is an essential activity and a Project Initiation Document or PID provides a place to store it.

Project Initiation Documents are nothing new and are part of many formal Project Methodologies. Too often when projects have problems, attempting to understand what’s going wrong and why can be difficult. In a poor project environment – things often go undocumented, and trying to unravel something that was agreed in conversation can be fraught. PID’s are good practice as they capture key information that can be used for reference throughout a project for guidance or when clarification is required. They also provide a method of communicating the benefits and business case that prove a project should be commenced in the first place.

Producing the PID at the right time is essential – the PID should be produced while the Project is being started. It can be authored by a mix of the customer and the Project Manager and should ultimately summarize your project in one document. As Projects can be big/small, simple/complicated the actual construction of PID’s may vary from Project to Project but there are some fundamentals that you should consider including in your PID.

Popularity: 5% [?]