Showing posts with label Project Management. Show all posts
Showing posts with label Project Management. Show all posts

Thursday, 12 November 2015

Is the PMP exam worth while

I am a member of a few groups on the social media site, Linkedin.com.  Recently, a member of the group called "Project Manager Community" asked the following question : "Does having a PMP state you're a better PM compared to one that doesn't have this certification?".

So far, there are more than 110 comments and they are still continuing to be added. 

My answer was to comment that it is not just the qualification, but that it must be combined with experience to make a good PM.  The depth of knowledge that the PMP exam makes each candidate understand is far superior than any other PM exam that I have seen, or indeed taken.  Each candidate must know the PMBoK inside out and understand the complexities and dependencies of project management.

Thursday, 19 June 2014

Social Media

Using social media for professional purposes is becoming common practice amongst the workforce in recent years.  People have been expressing their views, opinions, sharing news of their projects and career to the world to see.  Social Media has been used as a marketing tool for both individuals and companies.  For example, I use this blog to share my thoughts on Project Management and my career and different blog (Link) to share my thoughts and projects with Lotus Notes.  I am no longer a Lotus Notes "Guru", but I maintain the site to share any technical blog posts, keeping in touch with the community.


Tuesday, 25 March 2014

Supplier Contracts

One of the many pre-project, or early tasks for a project manager is to arrange the supplier contracts.  In the last two client assignments, I have had to find and secure contracts with a multitude of vendors for various provisions.  Some vendors have been used for consulting, others have supplied software and a few have supplied hardware.  Often, a client will have a preferred supplier list that you have to work with.  Sometimes the supplier list is constrictive and cannot deliver the required service or product, so you have to take a recommendation to the project steering committee to gain permission to pursue a new supplier.  This can cause delays, as the on-boarding process can take considerable time and effort, especially in larger companies and corporations.

Monday, 20 January 2014

My year in 2013

2013 has been a successful year.  It has been a good year in both my personal life and my working life.  I worked for two large corporate banking clients, had the biggest turnover for my consulting company, I passed the PMP-RMP exam and have seen both my children continue to grow into pleasant little creatures and are both excelling at school and extra-curricular activities.

Monday, 30 December 2013

MoSCoW


This is a short article to explain the fundamentals of the MoSCoW concepts.  I have been using RAD (Rapid Application Development) for many years, while being a Lotus Notes developer.  

Rapid Application Development does not mean lazy programming or rushed projects, but is a methodology that allows the Project Manager to cut out the "fluff" in projects and applications and to develop the right product, suited to the environment it is designed to work in. 

The 80/20 Pareto Rule means that a few (20 percent) are vital and many(80 percent) are trivial.  The concept of MoSCoW, it to concentrate on the vital deliverables and save the trivial to the end, or cut them all together.

Must haves - The "M" of MoSCoW, is for the priorities, the tasks that must be delivered, otherwise the project will fail.  For example, if building a house, these would be the walls and roof.

Should haves - The "S" of MoSCoW, is for the secondary priorities, the tasks that need to make the product complete and without them, the product will be functional, but not as functional as it should be.  For example, if building a house, these would be the plumbing, insulation, electrics, windows, flooring, fixtures and fittings.

Could haves - The "C" of MoSCoW, is for the additional tasks that would produce the best product possible.  For example, if building a house, this could mean the addition of a swimming pool.

Won't haves - The "W" of MoSCoW, is for the tasks that will not be completed.  If the project had all the time and money in the world, these tasks may eventually be completed, but they are superfluous to the final Product and therefore will not be delivered.  For example, if building a house, this would be the Helicopter pad.


As I said, this is a very short article, but a useful one, I hope.


Monday, 9 December 2013

Project Time

Time is part of the Project Management Golden Triangle.  I have blogged about the Golden Triangle before, but the concept is that you have Time, Scope and Quality, as three sides to a triangle and they all impact each other.  If you extend one side of the triangle, one or both of the other two sides will be impacted.

Time is an important aspect of Project Management.  People who understand scheduling will understand how simple and how complicated time planning can be.  On larger projects, the project plan will be controlling many different work streams in parallel and the Project Manager needs to understand the impact of time on each of the work streams and resources. 

Thursday, 5 December 2013

Introduction to Change

Part of the overall project governance is the Change Control.  This can refer to changes in the scope of the project, the budget, the Schedule, the services provided or the products the project produces.  Change control needs to be in place to ensure that the project is delivered on time, to budget and delivers the required product.  Change control ensure that any change introduced to the project is defined.

Thursday, 12 September 2013

When a Project becomes a Program

A Project is a temporary endeavour undertaken to create a unique product, service or result.  This is the definition from the PMBoK guide from the PMI.  A project is not a permanent fixture, including resources, budgets and teams, it is only in place to produce the final product.  A project has a defined end and can be stopped, if the end is not going to be achieved or is no longer a business requirement.

A program is a set of related projects which are managed in a coordinated way to obtain benefits not available from managing the Projects individually.  Programs will contain projects, but Projects may not necessarily be contained within a Program.

Tuesday, 10 September 2013

Scope

This first item on the Project Manager's agenda when commencing a project is usually to define the scope.  In many corporations either a Project Charter or a PID is created and approved before the project is authorised.  This single document contains the scope of the project and the business justification.  Importantly, this document authorises the project to go ahead and confirms the name of the Project Manager.

The scope document is often referred to throughout the life cycle of the project and is used by all stakeholders to confirm the direction of the project.  Where the Initiation document provides an outline of the scope, a further breakdown and detail must be confirmed.

My current project is having difficulty defining the scope.  Some of this is due to budget reasons and some of it is down to communication issues.  My current client is a Japanese bank.  The communication issue is not just the language, but the culture.  I have previously written an article relating to the culture of a Japanese corporation.

Tuesday, 16 July 2013

Does a PM need to understand the technical level of the project subject?

This was always a question playing on my mind throughout the time I spent as a consultant.  My specialist subject was Lotus Notes/Domino and I was at the top of my tree.  Throughout my career, there was not a problem that I could not solve with assurance and conviction.  People often tested me, but I would often indicate a possibility of three solutions to the problems they faced.  At the technical level, there was not anything I did not know.

Friday, 14 June 2013

Project Governance

Project governance is the framework which ensures that the project has been correctly conceived and is being executed in accordance with best project management practice and within the wider framework of the internal strategies and processes for each organisation.

Project Governance provides a centralised strategy for project control and reporting, including a set of rules of engagement and guidelines with project teams including external parties.

Friday, 24 May 2013

Agile Methodology

As I mentioned in a post last week, I have consulting at a client site that uses an Agile Project Management Methodology.  As a Project Manager, I had thought that I have not used Agile before, however, I now understand that as a Project Manager / Developer for many years, I have previously been using an Agile methodology.

In my very first job, after leaving university, I was coding a 4GL, and our Project Management Methodology was DSDM (Dynamic Systems Development Methodology).  I went on a course and actually became a DSDM Practitioner.  This was back in 1997.

Wednesday, 3 April 2013

Two Project Managers

Can two Project Managers work on the same project?
I think they can, as long as the relationship is clear and the roles and responsibilities are defined from day one.  Management above the project must buy-in to the concept of having two project managers and must agree to the defined R&R.

I am working on a large project.  Within 6 months, working on the initial concepts, designs and plans in the initiation stage of the project, I realized that there was too much coordination, communication, vendor management, internal team management, user management and reporting required for a single Project Manager.  I needed help and I was not afraid to ask. 

We now have two Project Managers on the project and it is working really well.  I am an easy person to build a relationship with.  I will trust and accept any person, until they cross me or my team.  The new Project Manager has a wealth of experience and is a great asset to the Project.

People within the Project Management Department often comment that there are two Project Managers working on the single project, but I see no issue with it.  Slowly, the colperets are coming around to understanding that the Project has a requirement for two Project Managers to work in tandem together to be able to achieve the final delivery in the manner that the corporation requires. 

Usually a Programme will have many Project Managers, but usually a project will only have one, however, due to the size and structure of the project, this project warrants the use of two project managers.

Defining the roles and responsibilities between us was an important "first day" task.  Over the past year, I had built relationships with vendors, internal technical team, management and the business.  The one part (and important part) of the Project Management I failed to keep on top of was the reporting.  My direction as a Project Manager is to "get the job done", so I did.  I covered all bases, ensuring that we had the best options, decided on the best solutions, worked with the best people and built relationships to ensure we obtained the best deals for the company I am working for.  This was all to the detriment of the reporting side and the management of the stakeholders.  A bad mistake.

The other Project Manager will take care of all of the governance and the management reporting side of the project, leaving me to run with the vendor engagement and the management of the technical teams to deliver the product.  I am a Project Manager that focuses on the delivery rather than the Project status updates and the "Project Management" side.

Have you ever worked on a single project, with another project manager? What was your experience, what worked and what didn't?


Friday, 23 November 2012

3 years continual learning

Now that I am a PMP, I will continue to develop as a Project Manager and gain more knowledge, understanding and most importantly, experience. To maintain my PMP status, I must complete 60 PDUs (Professional Development Units) over the course of three years. There are two main categories of PDU, which are for Continued Education and Giving Back to the Profession.

Wednesday, 21 November 2012

The PMP Exam

Let me start by saying this exam is tough, but it is not impossible and once you ensure you understand the concepts, it is fairly intense, but it is straight forward to gain a pass mark.

I would recommend that you have at least two or three years Project Management experience before attempting to take this exam.  You need to have completed a few projects before you attempt to even read the PMBoK guide, otherwise you may find it very confusing.  Some people advise that you start with other books before attempting to read and fully understand the PMBoK Guide, but I did it the hard way.  I had a few years of experience as a Project Manager and had obtained my Prince2 Practitioner Certification, so I already knew a considerable amount of Project Management Theory.

Thursday, 15 November 2012

Next week is PMP Week

Next week, I am going to write a series of articles which will explain, in very simple terms, what the PMI PMP is all about.

I will give a high level explanations in five separate articles, published from Monday through Friday, which will explain the following topics.


  • Who is the PMI and what is PMP?
  • PMP in a nutshell
  • The PMP Exam
  • What does PMP mean to me
  • 3 years of continual learning

When Project Managers talk about professional qualifications they often mention two exams, these are the Prince2 and the PMP qualifications. 

Prince2 is overseen by the Office of Government Commerce and is used in many companies including the government in the UK to manage projects in a controlled environment.  The PMI (Project Management Institute) has several categories and levels of examination, however, I will only focus on the PMP (Project Management Professional) exam.  I currently have both of these accreditations.

I hope to give a simple overview and some useful tips for the exam (Quick hint: study, study and more study). 

Thursday, 8 November 2012

Working backwards

Working backwards from a fixed deadline is something that happens in many projects, but it is something that has never happened to me.  My programme manager came to me yesterday and asked for my project to be finished on a certain date.  He needed to know how this would affect my project and wanted to report to his management team that "it could be done" !

I set about the task, knowing that I need to shave off approximately three months from the plan that I put in front of him, just the day before.  I knew a considerable amount would be swallowed up by adding additional resource, as my plan was only draft and only included man days, without any resource leveling.  I also knew that a few of the tasks could be performed in parallel, as long as there was additional resource, which results in increased cost.

My first task was to understand the deadline.  When he said that the project had to be completed within a particular month, I needed to understand if this was a specific date, or could I make it the last working day.
The second item running around my head was to gain an understanding of the project scope.  Could we cut some scope, would other project dependencies be ready earlier and could we introduce a phased implementation, completing the basic scope for the tight deadline and then having a second development and implementation phase for the remaining scope.

The next piece of the jigsaw to deal with was the resources.  At the moment, as in most companies - I am sure - there are many projects fighting for the same resources to build, develop and implement new projects.  To overcome this, I was told I had carte-blanche over resources and could basically specify the task and then speak with the individual team leaders to understand their resource requirements.  This requirement would then be reported to senior management and we would either recruit, or the schedule would have to change.

Remember the golden triangle... Time, Scope, Cost.  You cannot change one, without affecting the other two.  If I was to cut time, it would potentially increase cost or reduce the scope - or both.
Reducing the time is a usual request for a PM and this can come with some considerable increased risk.  It is up to the PM to understand and report these risks up the management chain and to mitigate as much as possible, without increasing the costs too significantly.

This was an interesting project approach, one that I was very comfortable with, but one that I would prefer not to repeat too often.  I agree all consideration should go into producing an accurate project plan and to ensure the scope covers the business requirements.  The PM must then deliver the scope and keep a tight reign on the budget and time.  By all means, throw resource at project tasks, but be careful of your budget.

Thursday, 26 April 2012

How tight do you run your projects?

I submitted a project plan, along with costs to the senior management last week and was told, off-the-record, that my timescales were too short and the expense budget was too small.

I have been a PM for a number of years and I am often told that my budgets are either too high or too low.  At the beginning of a project, this often concerns me and I always wonder what I have missed, or what the other person knows... that they have not told me.

I have the disadvantage, in one way, of a being a contractor, but also the clear advantage of being a contractor in another. 

For the disadvantage, I do not know the project history or "norm" within the specific company.  I do not know if projects historically tend to run to time and budget.  I do not know if suppliers are particularly difficult, or is procurement can hold the ordering and payment processing up.  I do speak to the other project managers and build relationships with all parties involved, from procurement, finance, technical teams and testers etc and I do find if there are any lessons learned from previous projects, from either the project managers or the PMO department.

The advantage I have is that I know different companies work in different ways.  To mitigate this, I build the relationships between the key teams and make sure that they can accurately estimate their timescales, costs and highlight any risks and issues for me.  I of-course build in a certain percentage of time and additional cost to enable any overrun.

What are you best tips for dealing with forecasting within an unknown company?

A Project Manager's CV

I had a CV come across my desk this week, which was given to me by a very reliable source.  The CV on first impressions looked quite good, with over 16 years of Project Management experience, all in the Investment Banking industry.

I looked at it in a little more details today and realized there was very little detail within the CV.  It made me wonder what level of detail we should go into on a CV.  My thoughts are that there should be enough information for each work placement to give an outline of what you have been working on, but leaving out enough detail to be a feeder for a discussion in the interview.

As a PM, I would suggest you explain the basics of any project you have managed, along with the timescales, budgets, project team size and any technology used, replaced or removed.  Again, I would suggest this is at a high level as to not give away any confidentiality and to keep enough information back for interview questions.

In addition, I would highlight any particular issues or risks that were dealt with successfully along with any management reporting levels, SLAs, third party vendor communications etc... All of this I would see as secondary to the actual project details listed in the paragraph above.

The CV in question only came with the secondary information.  I understand it was from an investment banking background, but there is still a certain amount of detail you can add to a CV without it breaking any confidentiality agreements... or am I wrong?

Wednesday, 22 February 2012

What is a PID

A PID is a Project Initiation Document and is created once the authorisation to initiate a project has been given.  The PID is the final result of the initiation phase of the project and describes the "what, why, who, how, where, when and how much" of the project.  This document is fairly extensive within the Prince2 Project Management Model and will incorporate many documents, such as the project brief, project scope, project definition and project plan as well as the strategy for the project in terms of communication, quality, configuration management, risk and issues.  More information on these individual topics can be found in the Prince2 book, so I will not go into detail here. 

It is the project managers role to produce the PID and pass it on to the project board for authorisation.  In reality the stakeholders, users and business analysts will need to be involved in producing much of the documentation. 

The PID is a constantly evolving document and remains important throughout the project life cycle.  The PID contains many documents/sections including the project plan, exception plans, risks/issues and therefore is updated throughout the project.  It remains a reference point to who is doing "what, when, how, why". 

Spend time keeping the PID updated and authorised.