First time visitors read!

If you are new to this Blog, read about it's purpose and how to get the best from it

Free Project Management Training

Go through the site content in a structured manner to teach you Project Management or improve your success rate

No English?

Can't speak English? No problem!!

Why the Sheepdog Analogy?

A Project Manager is a necessary evil. Why? Well, the PM doesn't produce anything - write code, lay concrete or whatever. However, don't have one and see what happens!

Always telegraph your Punches as a Project Manager

Sometimes as a Project Manager you need to throw a "Project Manager punch" but not a literal one please!

Isaac Newton's contribution to Project Management

Newton's laws, especially his first law of motion, should be as important to a Project Manager as it is to a Physicist. Why?

O Sponsor, Sponsor! wherefore art thou Sponsor?

You are given a project to run. Amongst your early questions should be, "who is the Sponsor?"

Always remember the Human side

It is very easy to get hung up in the technical and management side of Projects and forget that they need to be delivered by human teams. So "Always remember the human side" is the key phrase!

Why writing a Project Status Report is not a chore

I've met several Project Managers who view writing any Project status report as a chore. I think the opposite.

Planning is the key Project Management discipline

I have been asked a few times, "What are the top xx things to focus in on as a Project Manager? If pressed, I always fall back to Planning

Sunday, 27 December 2015

Considerations for picking up an in-flight Project

As a consultant I've had the telephone call a few times "Can you come and pick up this in-flight project?". Sometimes the client mentions the word "recovery", sometimes not, but if you assume the worst you typically won't be disappointed! In any event I always look to assess the health of the project within the first few weeks and in this post I'll take you through the approach I take.

Start with the Project Definition

My first reference point is to read the Project Definition document as this is the foundation of any Project. Checks I make include:

Look for the Business Case too

  • Is there a Business Case?
  • What is the linkage between the Business Case and the Project deliverables e.g. specific requirements to be met

How has the Project progressed against the plan as stated in the Project Definition (Evidence of Monitoring & Control)?

Evidence of Project Governance happening?

I will look for evidence of good Governance processes in place
  • Are there future Project Board meetings in the diary?
  • Is there evidence of previous meetings - Project Board Packs and Minutes/Actions?

Above all - listen to people

You should organise meetings with various stakeholders and key Project team members, fire some open questions and listen to how they respond. This should reveal useful information and views about the status of the Project as well as attitudes and the human side in general

Conclusions and an Example

You have made your assessments and you need to need to decide what remedial actions are required, if any. Sometimes you may need to have some hard discussions with your Sponsor and Project Board. You need to do this in the first few weeks before your "honeymoon" period has ended.

I remember one in-flight IT project I picked up for a new system development and assessed there wasn't a 1 in 100 chance of making the "planned" delivery date even with remedial actions despite the project being reported as on track. I had "the hard discussion" face to face with the Sponsor to say this and stated that I would replan, descope some functionality to deliver the remaining key functionality as soon as possible (I gave him an approximate date and confirmed within 2 weeks) and essentially prove the team could deliver something versus cancelling the whole project. 

Clearly he was not happy at all but eventually agreed to this approach. Based on good evidence of progress towards hitting the delivery date (which we did), he agreed the additional funding to deliver the Release 2 (the remaining functionality which was de-scoped from Release 1). So a (reasonably) happy Sponsor in the end and a Business Case that was not too badly compromised.

Sunday, 13 December 2015

And now, the end is near, And so I face the final curtain

"And now, the end is near, And so I face the final curtain" to quote the song "My Way". A Project is a temporary endeavour with a start and end point. So what are the things to achieve as you approach the "final curtain" with the team leaving the "stage"?
Project Closure - the final curtain

Any Remaining tasks for the team?

Check if there are any remaining tasks for the team, for example:
  • Are transition to BAU operations activities needed and if so, have they happened? If not, they need to.
  • You should have a lessons learnt session and prepare the lessons learnt output either as part of separate to the Project Closure Report
  • Are there points which need to be addressed which it is not practical to keep the Project going for? If so, owners need to be found to take these forward (see Closure Report below)

Roll-off Team

In many Projects your team cost money booked against the Project Budget so as you enter the Closure phase you may have already rolled off a number of the team (with maybe some call on their time for lessons learnt sessions etc). So you should look to finish the roll-off plan including you as Project Manager. Forecast the last week you will charge costs to the Project and thus you can finalise your Project spend against Budget. For other roll-off considerations see this post

Closure Report

The measurement of the success of the Project has two dimensions and the Closure Report is, in part, an assessment of the Project Team dimension ("Project Performance"). The sections I would expect to see in a Closure Report are:
  • Background, key objectives and summary of Business Case (links to documents with more detail).
  • Summary of Project Approach adopted.
  • Key Products delivered including purpose, version status and links to location in the Project File.
  • Team Member details (the BAU team may want to confirm a point of detail at some time in the future).
  • Performance - Time. Table showing key milestones (ideally those published in the Project Definition augmented by any added during the Project), the Baseline date and the Actual date achieved with comments as appropriate. Normally there is one or several primary milestones defined in the Project Definition objective, these should be highlighted (e.g. in IT Projects it might be Production System Release Date(s)).
  • Performance - Scope. Was the baseline Scope delivered or was some of the scope removed or potentially additional scope delivered (identified via Change Control)?
  • Performance - Quality. Quality metrics should support any statements, for example in IT Projects this might be the number of Post go live "warranty incidents" which needed resolving.
  • Performance - Costs. Comparison of actual costs spent versus the baseline in the Project Definition.
  • Performance - Benefit Case. Has the benefit case changed at all through the Project life-cycle?
  • Change Management - was what the effect of Change Requests during the Project life-cycle (link to Change Log)
  • Risk Summary - are there any open risks to be monitored by BAU Operations?
  • Issue Summary - are there any open issues to be resolved by BAU Operations?
  • Post Project activities - this is an important section stating activities which need to be completed post Project closure and who owns these actions. Ideally this list will be policed by some residual body such as a PMO. An examples might be Benefit Realisation steps / checkpoints .
  • Summary of key lessons learnt with a link to the full report

What about the Benefit Realisation?

The other dimension of Project success is reaching the target benefits and these typically are realised post closure of the Project. Hopefully it is clear who is accountable for these and when they will be reported (and who will this report go to). See my post of Benefit Realisation

Project Celebration

Hopefully you have had a successful Project and have a happy Sponsor. Ideally there is sufficient Project budget (or raid a BAU budget) to allow for a celebration event for the Project team. Discuss this with your Sponsor to agree the format, formal or informal, does the Sponsor want to make a speech etc? 

If you are appropriately skilled (or find someone on the Project team) why not have a Project Song which everyone can sing at the celebration event! I play the piano and have done this a few times now. One of my best attempts at this was for the celebration of the Risk Reward Project (concerning optimised Energy Trading). I managed to work in some key names from the Project team, operational teams affected (with business terminology introduced such as R-R-B, the Risk Reward Band) as well as mentioning that the Sponsor, Fran├žois, was happy a few times :-) [if you want to watch, ensure you are displaying captions to get the lyrics]




Risk-Reward, Risk-Reward
Risk-Rewards' on the drawing board
Ricardo does deduction, Pete does the construction
Soon there is a system good to try

Risk-Reward, Risk-Reward
Risk-Reward has really scored
The Board are most contented
Objectives now cemented 
Francois is a really happy man

Everybody knows the R-R-B
All of Risk will smile when we keep inside it
Maybe, you can never be sure
We exceed it, then
CHPO have the cure!

Risk-Reward, Risk-Reward
Risk-Reward has really scored
The Board are most contented
Objectives now cemented 

Francois is a really happy man

Tuesday, 1 December 2015

Rolling off Projects - After the Lord Mayor's Show

Near the end of your Project (and potentially at various stages before that) you may need to "roll-off" team members. This post considers the planning and execution of this including consideration of a potential anti-climax for the team members concerned - as we British call it "After the Lord Mayor's Show"


After the Lord Mayor's Show?

"After the Lord Mayor's Show" is a British proverb for anti-climax. The Lord Mayor's Show is a colourful and historic parade to welcome in a new (city of London) Lord Mayor each year. There is a long precession of marching bands and floats which travel through the streets of the city of London each November. After the parade has passed, bringing up the rear are cleaning vehicles to remove the horse manure. So in the Project context the proverb is saying "after working on a Project with excitement, pressure and achievement what an individual may face may be considered boring"

Consider impact on individual being rolled-off

I have observed several times when team mates have been rolled off near the end of a major Project a feeling of anti-climax of going back to a Business as Usual (BAU) role. It can stimulate thoughts of
  • "Let me take the experience of the Project and move onto another organisation"
  • "I don't feel motivated by going back to my old job"
While this isn't strictly in the Project Management remit, I like to brief the line management of what I consider are BAU Risks for them to own and as I always say, Attack the Risks before the Risks attack you. So proactive action may stop the loss / de-motivation of staff moving back into a post Project BAU world.

Planning considerations

As part of your ongoing Project monitoring and control you should be assessing if and when resources should be rolled off the Project. Projects differ in their funding arrangements with the most stringent (in terms of the focus for a Project Manager) being where all resources are funded by the Project budget. If you are in this stringent environment you should take a look at my post on Cost tracking

So at least once a month, look and plan ahead for resource release dates and / or resource extensions should a previous arrangement / booking no longer be correct. And for those of you running IT Projects, don't forget the vital non human resource of Environments which are known to kill Projects! So, for example, do you need to extend an environment booking because testing is not due to complete on time?

You need to consider local processes for rolling off people which may range from a quick email to invoking a termination clause in a contract. So work backwards so that you can establish the time to press the Go button to achieve a release date in line with the plan execution. Don't forget the human side, so have a discussion with the individual concerned about leaving the Project. You never know, they may give you a very good reason why you should delay the roll-off process!

Conclusion

As part of your monthly monitoring and control activities on your Project you need to consider whether to initiate processes to roll people off at some point in the near future. Please consider the human side by having a good exit discussion and brief line management about the risks that come "After the Lord Mayor's Show" 

Wednesday, 18 November 2015

Tips on Tracking your Project Costs

While you Monitor and Control your Project Plan, don't forget to do the same with your financial spend else you may be in for an uncomfortable Project Board :-) Here are my tip on tracking your Project costs.
Ensure you are tracking your Project costs

Your approach to estimation of budget should allow for Monitoring and Control of it

When you Initiated the Project, you should have established your Budget with the means to track spend to date and forecast to complete the Project and/or Stage. I previously described my tips on production of the Project/Stage budget and this post builds on the approach described there.

The first section of the Project Cost spreadsheet I use covers the Forecast and this can be maintained in line with any revisions to the Project Plan (e.g. we need an additional Contract DBA resource starting in 3 weeks time running for 3 months before being rolled off the Project)
Project Costs - Forecasting Cost over time

Below this is an Actual Effort section for the same billable resources. Note that although I like to plan in days, typically human resource costs are captured in hours so the forecast is calculated in hours here to allow entry of actual hours when known. This is typically taken from some time sheet system for human resources with a workaround strategy for non human resources (so that you can effectively add in the cost, covered in the preparing Budget post)
Project Costs - Calculating Actuals and maintaining Forecast to Complete
The remainder of the spreadsheet calculates the costs to date (as defined by what weeks are marked "A" for "Actuals") and the forecast to complete the Stage or Project. As the cost forecast is provided on a week by week basis, you can see and report on "burn rate" over time going forward.

Your own spreadsheet trackers are useful but there is "one source of the truth"

Your own spreadsheet trackers are very useful but there is really only one source of the truth and that is what is within the organisations financial system. Typically a major project will be allocated a cost centre within this system and this should be monitored at least monthly. Typically your own tracker will be more up to date than the financial system so:
  • I sometimes report both figures with appropriate "as is" dates and explanation as to status
  • In line with organisational standards, potentially use accruals within the financial systems to take account of costs you know have been incurred but has yet to hit the financial system

Wednesday, 4 November 2015

If you can't Measure it, you can't Manage it!

There are various proverbs in the general business management world of the form "If you can't Measure it, you can't Manage it!". But is this applicable to the world of Project Management and if so in what ways? I have a firm belief that the answer is yes and in this post I will explain with some examples from projects I have run in the IT domain - but the principles should apply to all other project domains.
Measure to Manage

Business Case / Benefit Realisation

The Business Case should ideally identify Critical Success Factors (CSF) but these can be difficult to measure on an on-going basis during Project execution. Typically proxy measure(s) can be defined as an indicator towards achievement of the CSF. These are called Key Performance Indicators (KPI) and can be broadly categorised into:
  • Lead indicators - these can be measured during project execution
  • Lag indicators - these can only be measured after the project has delivered something specific and thus could be post project close-down
The measurement of Lead indicators can be built into Project Plans and assessed as part of Monitoring and Control activities. The measurement of Lag indicators often forms part of the Benefit Realisation Plan, the activities of which often (but not always) only occur post project completion

Task Progress measures

Let us start with measures that you can use with any plan, namely task progress. Whether you collect these measures weekly or more often depends on the project but do consciously consider measurement frequency and whether the task is on the critical path or not! 

My biggest piece of advise here is to avoid the "percentage complete" measure which is not a reliable means of measuring in my experience as illustrated in this cartoon.
Project Tasks progress quickly until they become 90% complete then remain near 90% complete for many weeks

Instead look to capture Estimate to Complete (ETC) which is a better measure. I ask for effort (hours) rather than duration because if a person can't spend all day on a task then to state the obvious, the elapsed time will be greater.

Another top tip is to try and enhance your schedule in the area of long tasks (I personally don't like any task greater than 10 days as a rule). In such circumstances, think about whether any intermediate milestones can be captured to provide a more concrete measure of progress rather than ETC. An example with a document drafting task is to understand the sections in advance and measure how many of the total have been completed. So you might have a milestone 50% of sections drafted. The danger here is that there is no measure of the quality but although not perfect as the proverb says "something is better than nothing" :-)

Look for other measures to support task progress 

So you have the basic schedule based measures in place. Now look for other metrics specific to the phase of work being undertaken. Ask the question, what data will give me an independent measure of progress or aid as a check on other measures? Let me give some examples specific to IT system development projects I have run:
  • Analysis phase - in a technical analysis migration project I counted the number of objects to analyse and the run rate to achieve the analysis within the planned time for this activity. With these baselines established, measuring the actual objects analysed twice a week gave a means of establishing whether we were on track, ahead or behind plan
  • Design - at one client we needed to produce huge end to end design document for a major system with lots of integration to existing components. We agreed the content section by section and split it between about 8 people. I built a specific Excel tracker to monitor sections being authored and delivered to the head architect who did the assembling and quality checks. This was checked daily to ensure we were on track.
  • Build phase - from detailed design identify the components to be built and tick them off when they have completed build and unit test. This is a good starting point (e.g. we have completed 40% of the component build) but some components may take more effort than others. This is where a build sheet can be used to measure whether we are on track to complete in the planned time with the agreed component list and available resource availability. I wrote a specific post on this "build sheet" approach
  • Test phase - there are lots of measures to look for! In terms of pure execution, establish with your test manager the "test case run plan", i.e. how many test cases should be executed (not necessarily passed) over time. In simplistic terms if I have (say) a 5 week test phase, I will look for a plan to achieve execution of all test cases at least 1 week before the end of the phase as you should anticipate some residual defects to fix and retest. I will also have metrics reported ideally daily around number of open defects at various statuses (raised but nothing yet done with, in analysis, being fixed, ready for retest etc). You need to look for being "over the open defect curve hump" ideally by two thirds into the test phase
So here are some examples I have used and whether you agree / disagree is not the point, I recommend that you to look for supporting progress metrics in your particular project circumstances.

Financial measures

The basic financial measure is "burn rate" - how much money is the project burning per week / month? This can vary depending on where you are in the project lifecycle as more resources are added or rolled off. So understand what you originally budgeted and what you are actually burning to see whether the project in on track to deliver under, on or over its budget.

Conclusions

I have hopefully illustrated the benefit of quantifiable measurements across many aspects of your Project execution whether progress monitoring, benefit monitoring or financial monitoring. But don't just take my word for it! Galileo said:
Measure what is measurable, and make measurable what is not so
I've just re-read an old post on Monitoring and Control and it covers similar ground. This proves something - it could be that my memory is failing or that this is a very important topic which is at the forefront of my brain. I like to think that it is the latter!

Tuesday, 20 October 2015

IT Applications to enhance Project execution

Many Projects survive on as little IT as the standard Office software suite, a shared file server and an email system. However there are IT Applications which may enhance your Project execution which you might want to consider. In this post I examine some different categories of applications, some examples and whether I have had any experience to share or not. I will no doubt update this post when I learn some more from your experiences!
IT Applications for Projects

Introduction and General Considerations

I have attempted to segment applications by broad category but very often the boundaries are blurred as capabilities are enhanced in each application!

In terms of general considerations, with any application you are looking to introduce to your project team there are some general considerations to bear in mind:
  1. Installation. The ease (or likely not) in installing the application within your organisation's corporate infrastructure and thus the time taken before it is available for use. The good news on this front is that there are many more cloud based applications these days so you maybe not impacted by this
  2. Training requirements. You need to assess what training is required and get this into the project plan. Even then you need to acknowledge the risk that the application will not be fully utilised. I refer you to my post on the resistance to any change

1-Project File applications

All projects need a well organised Project File - see my previous post on the subject. While a shared file server can do the job, one application is now heavily used to enhance the capabilities - SharePoint.

This allows document check-in/out, version control and can be used to create a common site for Project team collaboration with a little effort and use of web parts. Organisations running a number of change projects should establish a standard design so there is a commonality between projects.

There is blurring between my categorisation as several applications in the "collaboration" bucket seem to provide Project Files, so read down!

2-Plan Scheduling Software

To undertake critical path analysis, you need some IT support. Microsoft Project is probably the most frequently observed tool, in my experience it is good on user interface and presentation but in versions I have mostly used (v2003), it lacks something in effort based scheduling. I started life with Project Manager Workbench (PMW) which had a very good effort scheduling engine but lacked a good user interface. It seems this has moved into an open source application Open Workbench but I don't have experience of it.

Other alternatives (not used) include:
  • ProjectLibre billed as the open source rival to Microsoft Project
  • wrike - as well as project and resource planning, it claims to do collaboration, daily work management, progress tracking, reporting etc
  • Note that bigger application sets detailed below may have their own scheduling tool

3-General Project and Portfolio Management

In this category I include any applications aimed at supporting the running of Projects and Portfolios of projects. These can help support / enforce a Project Management methodology, provide templates and centralised reporting both for an individual project and a portfolio of projects. 

The application in this category that I am most familiar with is Project in a Box, as it provides a free version you can evaluate. In terms of competitors, I don't have any knowledge but you may want to take a look at:
  • ]project-open[ - an open source enterprise project management tool promising a lot
  • Glasscubes - seems to combine aspects of Project File, scheduling etc
  • SimPro

4-Enterprise Portfolio and Resource Management Suites

These are expensive suites of software which larger organisations, with a significant portfolio of projects (and corresponding resource pools), use. They integrate a number of features such as scheduling, resource management, time capture etc. Examples I am aware of are:
I actually ran a Project to introduce ABT across 450 users so appreciate the power of the toolset but these only work if there is considerable effort in establishing processes around the tool, training and ongoing policing (typically by a PMO). The same goes for Project Server which I come across in a number of client sites.

5-Traditional Collaboration Tools

"Traditional" Collaboration Tools help the project team communicate better and hopefully cut down on email traffic which is a danger in project teams - see my post on this. Things like wikis can be quite useful and I refer you to the most popular wiki, Wikipedia for a comparison of wiki applications including some open source.

The list of tools in this area seems to grow daily and the only thing certain is that I am out of date! Some I am aware of are:
  • OpenProject is an open source tool which promises a lot
  • SharePoint as previously mentioned should be included in this area
  • There are plenty of Cloud based Project / task focused collaboration tools such as BasecampWrike , asana, slack

6-Social Collaboration Tools

I have separated out collaboration tools which are more Facebook inspired. Again, these promise reduced email traffic which is no bad thing but I haven't seen any in operation. 
  • Yammer seems to be gaining popularity. Says their site, "Yammer is a private social network that helps you and your teams stay on top of it all. Yammer team collaboration software and business applications allow you to bring your team together so you can have conversations, collaborate on files, and organize around projects so you can go further – faster" 
  • Socialcast - "Connect, engage, and accomplish more" says their site
  • Jive - "Turn your intranet into a communication and collaboration hub" says their site

7-Tools to support Agile methodologies

I have categorised applications which seem more suited to supporting Agile methodologies
  • Trello I've heard, is a great tool for managing requirements / scope especially in an Agile environment. I've had a play but not actively used.
  • Taiga is open source and describes itself as a Project Management platform for Agile.

8-Others not mentioned elsewhere

  1. Instant Messenger tools - I am quite keen on the use of IM tools such as Skype / Lync to cut down on email traffic for conversations but I guess there will be competition going forward from some of the collaboration tools highlighted above
  2. Blogs can be useful for Project communications. Clearly there are a number of cloud based sites such as Blogger being used for this particular blog or you can install the application on your own servers (e.g. wordpress, ghost)
  3. Configuration Management tools. Sharepoint does the basics for project documents but for more complex project requirements (e.g. software development) have a read of my post of the topic
  4. Test Management tools. These are commonplace in system development projects covering test planning and defect management. HP Quality Center is the one I have used the most although I have also come across the open source Eventum defect management application, see a review here

Conclusions

I have just scratched the surface of applications which may be of use to your Project team. The world is moving so fast that the examples listed and even completely new classes of applications can be considered with significant cross-over between the categorisation I have attempted.

However I want to remind you that change isn't easy to achieve so bear in mind that by introducing completely new applications into your project team you run some risks of actually slowly down progress which clearly isn't the aim of the game! Plan for this eventuality and persevere to get the benefits.

Wednesday, 7 October 2015

Appointed PM for a new Project? - Don't Panic!

Congratulations - you are given the role of Project Manager for new Project X with likely stakeholder pressure to get going quickly.You then go back to your desk and may start panicking as you say to yourself, "where do I start?" "there is so much to do!". In this post I will take you through a check-list of things to consider in start-up / initiation linking to other posts to drill into some of the detail.
Appointed PM for a new Project? - Don't Panic!

The pressures to get going

Some stakeholders may see any Start-up / Initiation activities as "resting up" and there may be pressure to "get going". While I would conceptually resist this, I suggest two key points for you to consider :
  • manage stakeholder expectations - the best way to do this in my experience is what I call "plan the plan" i.e. develop a plan for the Start-up / Initiation phase which will produce a Project Definition including a Project Plan so there is a rationale for the "delay" (how it may be viewed) in getting going
  • I am the biggest defender of the Initiation process as a strength of Project Management foundations to build from but every strength can be a weakness. I suggest you consider whether some early work can be kicked off if resources are available. I have covered the rationale for this in a previous post

What are you given to start?

PRINCE2 and other Project Management methodologies define/imply that when appointed, the Project Manager will be handed a mandate / charter or other such document which "sets the scene" for Initiating the Project. I don't know whether I have been unlucky but in the main I have received very little documentation and certainly not a nicely structured "magical" document which answers questions such as: 
  • Background to and objectives of the Project
  • Constraints under which you should plan. This might include a specified approach or solution, maximum budget, time expectations etc
  • Key stakeholders identified
  • Statement of scope
  • Target benefits
So if you don't have this information you need to plan to obtain this as soon as possible. In terms of stakeholders, the most important is the Project Owner so if none is evident, this is certainly something to address as soon as possible as the Sponsor is a key stakeholder to interview to enable you to confirm firm foundations for your Initiation. Have a read on my post on the Sponsor / ownership Board.

Remind yourself of the end goal of Initiation

The output from Initiation is some sort of Definition document which is the contract between the Project Manager and the Project Owner. So in line with my post on Product Descriptions I suggest that, should you not be using a standard template, you agree what are the headings of this document which you will need to complete and this will start your mind thinking about how to populate the content. Have a read of my post on Project Definition which gives you these headings. 

Week 1 Check-list

Whether all of the following can be achieved in one week depends on the scale of the Project but hopefully you can adjust accordingly!
  1. Has a Sponsor been formally appointed? If not, who can act as a proxy in answering some of the immediate definition questions that will arise re point 2
  2. Study any information given and look to fill in gaps against what should be provided in a mandate / charter (see above) by doing some digging
  3. Make good progress with a draft plan to deliver the elements of the Project Definition and thus allow Initiation to exit including resources you may need in Initiation (see later for an example)

Week 2 until end of Initiation Check-list

  1. Secure Sponsor, hold a discussion and confirm any definition analysis to date
  2. Start progressing tasks in line with the Initiation plan. Draft sections of the Definition as you go along, don't leave it to the last moment
  3. I suggest that you operate an Initiation query log where you can jot down queries as they come to you and then you can review periodically to double check they have been addressed
  4. Remember that some elements may need several iterations so there may be rework but don't use this as an excuse for not committing anything down as going through the process of writing down elements are likely to bring out more points to clarify
  5. Ensure you have answered the following questions (which I am sure can be added to, suggestions welcome!):

  • What is the purpose of the project and what will it create? i.e. do we have a clear objective
  • What is the rationale for undertaking the project i.e. high level business case
  • Is the scope of the Project understood? Consider in and out of scope definitions
  • Who will be using the final projects products once they are handed over?
  • What are the intermediate products that need to be produced to achieve the final product (first part of planning)
  • Why should this project be started, and what is the justification for it?
  • Who will need to be involved to deliver the project?
  • Whereabouts will the project occur, and where will the products be built?How will the products be built?
  • What general approach will the project take in order to deliver the end product?
  • When and why must the project start and finish?
  • Have the constraints been identified e.g. budget, particular solution?
  • Is there a definition of in and out of scope aspects?
  • Have the stakeholders been analysed?
  • In terms of ownership should a Project Board be created and who fits roles of Senior User(s) and Senior Supplier(s)?
  • What is the Communications strategy?
  • Has a risk analysis been undertaken?
  • Have the costs of the Project been defined?
  • Is the Business Case sufficiently defined at this stage to justify the spend that will be requested?

Links to posts on the disciplines involved during Project Initiation

Within the Blog I have posts on the disciplines involved in Initiation. Use the Subject Tags (right hand side bar) to select these or simply use the search bar at the top, it works well!! As a starting point I will indicate a few key posts below:

Lastly - Acknowledge that emotionally, you may face the pit of despair

Emotionally you may be faced with a dip in your emotional curve when you pick up a new Project. There is a lot of information and questions to process and you may feel overwhelmed for a while. This is sometimes called the emotional pit of despair. All that I suggest is that you continue in a methodical way to work through the information, questions etc in front of you and in a short period of time you will come out the other side as shown in the graph below. Good luck!



Thursday, 24 September 2015

Project Lessons Learnt - remembering the past to influence the future

In this post I want to discuss the topic of Lessons Learnt within Projects. In football (soccer), if a goalkeeper lets a goal in through his legs, best that he learns from this for the next match. Or as the philosopher George Santayana said, "Those who cannot remember the past are condemned to repeat it".
Projects - Those who cannot remember the past are condemned to repeat it
I want to break down this topic into 3 areas:
  • Organisational Lessons Learnt (learnings from other Projects)
  • Project Team Lessons Learnt
  • Personal Lessons Learnt

Organisational Lessons Learnt

The principle here is that while initiating a new project, the Project Manager refers to a database of previous lessons learnt in the organisation for points to build into the plan or risks to consider.

I have come across this concept a couple of times as a consultant Project Manager but have struggled to gain useful insights from the database as:
  • it is difficult to find relevant lessons
  • the lessons are not written in a way to assist a new recipient
I don't have any particularly magic answers here but if I can find a similar project in the database (e.g. dealing with the same technology stack) and the Project Manager is still in the organisation, I will make contact and have a discussion about the previous project(s) and learning points as I am more likely to get some useful insights.

Project Team Lessons Learnt

PRINCE2 speaks of having a lessons learnt log and formally updated this at various points in the Project life cycle. My approach is to have a blank notepad file with a link on my desktop which allows me to quickly update with some pointers / thoughts as I come across them during the project.

During the project close-down phase you should organise a lessons learnt meeting but I recommend that in advance of this meeting you issue out a preparation sheet for some private contemplation by each participant in advance of the meeting. My approach is to:
  • list some key information about the project performance in terms of progress against plan etc
  • have life-cycle sections for focusing thought (for example in a waterfall system development project this might be analysis, design, development, SIT, UAT, implementation etc). I always have additional sections for management and teamwork.
  • ask the team member to list a maximum of 3 positive and 3 negative lessons per life-cycle section i.e. things that went well that should be repeated and things that went less well that we should do differently next time. 
Sometimes lessons learnt meetings can be very cathartic to get rid of team angst but in terms of capturing something which can be practically applied in the next project, pretty useless. I always try and focus the meeting on what could a new project team pick up and apply from this project and the preparation sheets can help focus the meeting appropriately. Gather up the sheets and your own notes (having a separate scribe can be useful) and try and distil this into something which can usefully be applied.

The meeting can also identify some consensus on individuals who have gone beyond their normal role is helping the deliver the project. This information can be used from a simple thank you to something more substantive whether a reward handed out at the project celebration event or input into the organisational HR processes.

Personal Lessons Learnt

Whether part of your team lessons learnt or separately, you should consider what went well and what you would do differently as a Project Manager next time. Try and get some honest feedback from the team and stakeholders on your performance and how people perceived you because it is often different from what you might think. While it can be challenging to implement changes at an organisational and/or project team level it is a lot easier to implement changes at a personal level so make sure you do! 

Thursday, 10 September 2015

Improving your circulation to achieve better Quality

No, I'm not proposing that you take more exercise (although this isn't a bad idea as per my post on handling stress)!! This is concerning the Quality processes for documents created by your Project. As I previously discussed, the most common but least effective quality method for documents is "review by circulation" where the author sends out a document in an email to a list of reviewers / approvers. Hopefully the document is fully reviewed by a number of people, comments are addressed and appropriate people sign off the document to confirm it is "fit for purpose". I have observed some very poor practices with regard to this review technique so here are my suggestions for getting the very best out of it although for key documents you may want to utilise better methods.
Review by Circulation Quality method - Bad and Good

Pick your reviewers and approvers carefully

I call this Quality Planning and was introduced in my previous post on the subjectSo consider who should review the document and why, who should signoff the document and why? Very often insufficient thought is given, the author just picks some random people sometimes only based on "status" within the Organisation or Project and here is where poor quality starts.

Let me take an example from the world of IT system development. Often some sort of Functional Specification is produced to define the system behaviour. Who should review and/or approve such a document to ensure it is fit for purpose for development to commence? Here are my suggestions but rather than get too focused on the example, I hope it demonstrates the thought processes in general terms
  • is there a need for a peer review before it is formally issued out for review? This will very much depend on the skills and experience of the author.
  • does the customer agree with this specification? Therefore a key approver should be someone senior on the Project Board who represents the user base. Often this person is named the Senior User, see my post on Project ownership. However, the Senior User should name the people he/she wants to be happy with the document within the user community - these will be reviewers
  • can we develop from this specification, is it unambiguous? To address these points someone senior in the Development team should review or maybe approve with named additional reviewers as suggested
  • will the IT tools available allow this specification to be met? Does the document support organisational design principles? Some Architectural review / approval is required
  • will we be able to test against the specification? Test team leads (for various test phases) to at least review
Of course, PRINCE2 says you should be producing a Production Description (PD) for this document which defines several things including quality process. But as per my post of the subject, I think you can get away without this in many cases as long as the rationale for the PD is handled elsewhere.

All reviewers and approvers should be named in the Document Control section of the document whether Word, Excel, Powerpoint or some other authoring software.

Plan! - give time for review, updating and final approval

Most document reviewing by circulation is unplanned additional work for the reviewer that they need to fit in between other work. So you should recognise this and give a reasonable time to properly review. What is "reasonable" will in part be controlled by the size of the document, to state the obvious, 100 pages needs far more time than 5 pages!

My rule of thumb is a minimum of 10 working days to get from the issue of a good first draft (peer reviewed before issue if author is inexperienced) to achieving a baselined (fully signed off) document. This can be broken down into something like:
  • issue good first draft requesting responses by end of Day 5
  • remind people when responses are expected around end of Day 3. You might drop into the email that you will be recording who hasn't responded!
  • 2 days to address comments, have side discussions if necessary = Day 7
  • issue final draft for signoff with responses to review comments = end of Day 7 requesting signoff by end of Day 10
  • chase down approvals as necessary

Be very clear in your email and set a deadline

Emails need to be very clear, have a read on my post regarding emails within Projects in general.

So I suggest
  • put some directive text at the start of the subject line - something like "PLEASE REVIEW: Project X Functional Specification 1st draft - comments by Friday 10 Apr 2015"
  • ideally have a link to the document in your Project File rather than attach the document but ensure that the reviewers have access to the respository
  • introduce the document context and the need for review comments
  • set out the plan (briefly!) to get to a fully signed off document and thus the importance of the deadline for initial responses state in bold and say that if responses aren't received in this timescale, your responses cannot be incorporated in the draft issued for signoff and that this will represent a risk to the Project

Send out a review comment template with your document and be rigorous in updating and sending out

I recommend issuing out a simple spreadsheet based review comment template with the document and request that all comments are returned using the template - see example below. 


Example Review by Circulation Comment spreadsheet
Review by Circulation Comment Template with author responses

The various comments can be combined into a master comment tracker spreadsheet. The comment tracker is then used by the author to methodically work through the comments and make a decision whether or not to modify the document as requested and the tracker can be updated accordingly. This tracker is then sent back either individually to reviewers or I prefer to send out to everyone as part of issuing the document for signoff. 

Track Reviews - "Name and Shame" strategy

The people who have supplied review comments are noted in the document and also the people who have not provided any response. Although this is good to note, even better for know that this will happen so that it encourages responses. 

Use Tracked Changes in the document after first issue

Once you have issued out a first draft for formal review, please track any changes in the document if this is possible. This will minimise the effort for reviewers and approvers to see that their review points have been addressed.

Chase down the Approvals

Be prepared to chase down approvals. Some people are busy, some people have too many emails, some people don't want to commit and some people think that by not signing off they can change their minds in the future. Every day past the planned date for baselining the document is a risk to the Project so chase down the approvals. You may even need to threaten to throw a punch!

Conclusion

If you have a really critical document pick a more effective quality process such as a Walkthrough review. But there will be a number of documents in your Project that you will choose to use the "Review by Circulation" quality method for. In such cases, careful planning and the use of specific techniques will give you the best quality document baselined on time.

Friday, 28 August 2015

The Product Based Planning technique is a great way to start your Planning

You are given a Project to plan, where do you start? Product based Planning is a powerful technique and a good starting point for your Planning activities. It produces a roadmap for the Project and ultimately identifies a good proportion of the tasks for your schedule. So if you don't know the technique, read on for how I tackle with a worked example using my favourite Project of making a Mug of Tea.
Product Based Planning - Mug of Tea

Work out final and intermediate Products - a Product Breakdown Structure (PBS) may be useful

The first step is to work out what Products are to be produced / utilised by the Project. The final one(s) should be easier to define but then you need to think of intermediate ones - those which are needed to achieve the final Products.

A Product Breakdown Structure (PBS) may be useful to tool to help in the thinking process and ensure that you have identified all Products.

It shows the breakdown of the final Product with intermediate Products and a breakdown of these if appropriate but doesn't imply any order of production. Some tips are:
  • the top of the structure is the Final Product
  • show Products NOT Activities (look for nouns or outcomes in the past tense). So don't confuse with a Work Breakdown Structure (WBS) which is concerned with activities. For example, "trained workforce" is a valid Product, "training workforce" is not. This may seem semantic but it is quite important
  • distinguish "External" Products which exist already (e.g. brought in, provided by another Project) versus "Internal" Products which need to be created by the Project
  • Products under another Product go to make the higher Product
Mug of Tea Project - Product Breakdown Structure
Mug of Tea Product Breakdown Structure (PBS)
The key to the above PBS is:
  • Rectangle - Product produced by Project
  • Eclipse - Product external to Project. So these become External Dependencies
  • Rhomboid - not a Product but a collection of Products
So here is my list for a "Cup of Tea" (actually Mug because a cup isn't big enough)
  • Mug of Tea - the final Product
  • Consumables - Teabag, Cold Water, Milk (all Dependencies as I am assuming someone else has provided these) and Hot Water which is a Product produced by the Project
  • Equipment - Mug, Spoon, Kettle (all Dependencies as I am assuming someone else has provided these)
In theory you should produce Product Descriptions (PD) for all these Products, but often I believe the information can be held elsewhere in your Plan as per my post on Product Descriptions

A Product Flow Diagram (PFD) is useful if the order of Use / Production isn't obvious

The Product Flow Diagram (PFD) shows the sequence of use / production of the various Products identified by the PBS. Here is the Mug of Tea example


Mug of Tea Project - Product Flow Diagram
Mug of Tea Product Flow Diagram (PFD)

This Product Based Planning now assists in production of your Plan Schedule

Firstly, the product list and sequence is a useful way of assessing Project progress outside the schedule by answering two key questions:
  • has the Product been produced?
  • has the Produce successfully passed the Quality process defined for it?
I have even used this basic approach as a simplified approach to measuring Earned Value, a topic I wrote a presentation about a few years ago.

Secondly, this gives you the framework to produce 80% of your Plan Schedule:
  • task(s) and resource(s) to produce the Product. Estimate effort to produce and thus duration
  • task(s) and resource(s) to quality assure the Product. Estimate duration (and effort) to undertake the quality plan (see post on document quality planning but other Products need quality plans too)
  • Some task dependencies implied by the PFD, others obvious (you can't quality assure a Product until it is produced!)
  • Don't forget Management Products (to operate the Project) if your Product based Planning has focused on Technical Products
So here are 80% of your tasks and a framework to fit the remaining 20% of tasks such as Risk management actions, Communications etc. With a bit of resource levelling thrown in, you have your Schedule - a great job all based on Product Based Planning!!

For the Mug / Cup of Tea example, you can take a look at my posts on scheduling
You may also want to look at my post introducing Planning

Twitter Delicious Facebook Digg Stumbleupon Favorites More