LATEST POSTS

Dear Reader,

While reading Raven’s Brain blog I came across an excellent article about 10 Undeniable Truths of Project Management Barnett sourced from Gantt Head.

1. Project Scope Is Not Defined On PowerPoint Slides

2. Project Schedules Do Not a Project Plan Make

3. Projects Are Not Managed From Behind a Spreadsheet

Some project managers secretly want to be statisticians. They love to calculate all of the various metrics pertaining to their project such as the percentages of deliverables completed, tasks currently on schedule, tasks that should have started, of variance from budget, etc. These are all good to know. The problem is that they spend so much time summarizing and restating data in their spreadsheets, they never talk to the team members about how the project is going and what problems they are having. Without that connection with the team, they are not managing so much as they are reporting.

4. No Task Longer Than 80 Hours and Not Shorter Than 40

5. No More Than One Person Responsible For a Task

6. Every Task Generates a Deliverable. No Work for Work’s Sake.

7. Large projects should be broken down into sub-projects (if they have long timeframes)

8. Plan for the Worst

The old saying is “the best laid plans of mice and men often go awry”, and they do. Always think through your risk plans. Even if things are going well, a good PM has to ask “what if?” Remember that for each risk you can think of, come up with a way to reduce the likelihood of it happening (mitigation) and have a Plan B if it does (contingency).

9. Make it Fun

IT projects can be daunting events. Have you ever noticed that there are some project managers that people just don’t want to work for? The Project Tyrant that is always changing things, asking for things at the last minute and making demands of people is someone that is hard to support over the long haul of a project. There will be tense times on any project, but the lead comes from the top. When things are at their worst, if the PM can laugh at himself it will relieve the tension of the entire team.

10. In the End it is People

In the end, the key point to be mindful of is that all of the previous techniques exist for one purpose: to produce results with a team of people. All of the techniques in the world will not produce anything if they are not constantly tuned, adjusted and calibrated for the individuals on your team. People are different and they all respond differently in various situations. The most successful senior managers I have run across in my experience were the ones with a unique respect, passion, appreciation and understanding for people.

What is the role of the PMO? What is its relationship with the Project Portfolio Management Process and Project Portfolio Management Team (PPMT) as well as the project management process? How can the true potential of the PMO be realised?

A project manager is a very different animal to the programme manager. However, the relationship within the business is designed to be mutually complementary. This is also true of the relationship between the PMO and the PPMT. Delivering complex programmes on time and on budget is a major challenge for any organisation. With diverse but interrelated projects, resources, and processes, conflicts are inevitable and success is often elusive. The biggest challenges facing most organisations today are
having the ability to know which of their projects are in trouble at any given time, and how they will get them back on track. With information and people so widely distributed, the critical ability to check project status and proactively identify problems can be next to non-existent. Moreover this is also compounded by disparate levels of project management knowledge, skills, abilities, techniques and methodologies from one business unit and department to another.

Disparate information and poor communication about project interdependencies typically result in:

• project delays: projects run late and do not deliver the desired results
• no standardised method: typically, many organisations have no centralised or enterprise-wide project management method, resulting in fragmented and ad-hoc compliance to project governance standards and procedures
• resource bottlenecks: key resources are chronically overscheduled and there is no clear method for project managers to get the right people for their projects
• out-of-control costs: redundant projects are occurring in different business lines and are costing the organisation more than estimated
• insufficient information: management has little or no insight into what projects are being undertaken, or how well they are being carried out
• no decision framework: projects are undertaken with little or no analysis, with projects having a strong champion or determined evangelist driving other possible investments out of consideration

Therefore businesses that want to improve project outcomes as well as provide critical project information for executives, or institute an analytical project decision process, are turning to the creation of a PMO – a means of managing projects within an enterprise environment.

Dear Readers,

I found an excellent article on the Value of a PMO from Project Steps.

For your convenience I have summerised the article below.

What Value can a PMO (Programme Management Office) Offer?

Establish and deploy a common set of project management process and templates. These reusable components save time by allowing projects to start-up more quickly and with less effort.

The PMO builds and maintains the PM methodology and updates it to account for improvements and newly discovered best practices.

The PMO facilitates improved project team communication by having common processes, deliverables, and terminology.

The PMO sets up and supports a common repository so that prior project management deliverables can be candidates for reuse by similar projects. This helps to save start-up time.

The PMO is responsible for PM training. This training helps to build core PM competencies and a common set of experiences. This PMO training helps to reduce overall training costs paid to outside vendors.

The PMO coaches project managers to help keep projects from getting into trouble. At risk projects can be assisted by the PMO to mitigate further issues and risks.

The PMO serves as a tracking mechanism for basic project status information and provides a common project visibility report to management.

The PMO tracks organization-wide metrics on the state of project management, projects delivery, and the value being provided to the business by project management in general, and the PMO specifically.

The PMO is the overall PM advocate to the organization. This could include educating and selling management on the value of using consistent PM processes, or as a liaison to other business centers to provide project management training and support.

One fact is clear from the research I have conducted, a PMO is critical when it comes to supporting sound project management practices. The larger the project the more project management (PM) can help to bring about success. It is readily accepted that good Project Management processes support:

A) Reduced Cycle Time and Delivery Costs
B) Improved quality of project deliverables
C) Early identification of project issues, budget, scope and risks
D) Reuse of knowledge and the ability to leverage that knowledge on future projects
E) Improved accuracy of project estimates
F) Improved perceptions of the project management organization by our partners
G) Improved people and resource management
H) Reduced time to get up to speed on new project

Dear Readers,

You may be surprised to find out that PPM derives its beginnings from the world of financial investing. PPM leverages the work of a Nobel Prize-winning economist to bring balance to an organization’s project activities.

Below is a short article from the project and programme web portal Gantt Head about Dr Harry Markowitz who created a theory about investment that would change the world.

The World of Modern Portfolio Theory
In the early 1950s, Harry Markowitz–an economist at the City University of New York–created a theory about investment that would change the world. He created a unique approach to investing in stocks and other assets. Unlike traditional asset management, which focused on predicting individual stock price movements using fundamental or technical analysis, Markowitz focused on evaluating the performance of a portfolio of assets based on the combination of its components’ risk and return. His hypothesis and subsequent work were so revolutionary that Professor Markowitz was a joint Nobel Laureate for economics in 1990. This system has become known as the Modern Portfolio Theory (MPT).

However, this theory had to wait for advances in computer power to become fully available. Because of the complex financial analysis and models used to predict a stock’s potential risks and return within a portfolio, computers were needed to perform the analysis.

At the core of MPT is the concept of diversification. Diversification helps spread risks between investments while continuing to achieve returns. Modern portfolio analysis has shown that even a random mix of investments is less risky than putting all your money in a single stock. The crucial insight of MPT is that risks found in individual investments matter little when compared to its contribution to the risk of the portfolio.

Thus, diversification involves a trade off between risk and return. MPT makes some very reasonable assumptions about the way investors behave regarding risk. Although some investors can take more risk than others, investors are assumed to be risk-averse. A risk-averse person is one who, when faced with assets which promise to provide the same return, will choose the asset with the lowest risk. In order for investors to accept higher risk, they will want to be compensated with the potential for earning a higher return, and vice versa.

MPT and Project Portfolio Management
As the concept of MPT filtered into the investment world, giving investors and fund managers new tools for assessing risks and returns on a portfolio, business leaders and professors began to look at this theory and how it would apply to the corporate world. Early articles like the 1981 Harvard Business Review article “Portfolio Approach to Information Systems” by F. Warren McFarlan attempted to describe how creating a portfolio of projects and managing these projects together could minimize disasters and increase results from projects.

Project Portfolio Management takes the concepts of MPT and applies them to the three key evaluation criteria used to measure projects: the costs to undertake the project, the risks involved in the project and the potential returns on the investment. Portfolios are created of similar projects (projects of similar types, durations, requirements or goals) and are managed as a group.

By pooling the projects together, the risk of the portfolio can be managed by tweaking the projects within the portfolio. One project’s mix of high risk with high potential return may not be acceptable by itself, but when mixed with other low-risk projects, it may become acceptable to the company. Projects become investments to portfolio managers, and corporate approval for activities occur at the portfolio level and not at the project level.

The key questions to ask when choosing a Software as a Sevice (SaaS) model are:

• Who owns the data?
• What are the levels of support?
• How do users access the software application?
• How are service issues resolved?
• How are questions and/or problems concerning the software resolved, and what happens next?
• Is training provided?
• How secure is the data?
• What are your internal security policies in respect of allowing SaaS employees to have passwords and access to reports?
• What are the security safeguards against external attack, and do you provide backups to handle hardware failures?
• How secure is the connection between the infrastructure and the user? Is it secured by encryption, a VPN, proprietary techniques or some other system?
• How is the application served, is the data on a dedicated machine or a shared machine?
• How does the SaaS provider handle redundancy? What levels of redundancy are in place to keep your servers online?
• How does the SaaS provider handle hardware/software problems?
• How does the SaaS provider handle a disaster such as fire or flood?
• How would the SaaS provider handle the complete loss of the facility?
• How long would it be before they restored service?
• How can you get the data out if you choose to select a new SaaS provider?