Archive for the ‘IT’ Category

Managing Large Projects or Programs

Posted on May 7th, 2013 in - Bruce Beer, Best Practices, Budget, Communication, IT, Lessons Learned, PMO, Project Management, Reporting, Resources, Schedule | No Comments »

By Bruce Beer, PMP

OK – you have been asked to manage a new major project that is an integral part of your company’s strategy (or your customer’s strategy if you are providing project services) and the cost is estimated to be in the 8 to 9 figure range.

Where do you start?

A very large project would probably be a program (a group of related projects) rather than one single project, so you would probably need a Program Management Office – PMO – to manage this juggernaut. I would suggest that in most cases you would start with the PMO management infrastructure. Assuming you are to be the program manager, on a major program you will probably need a deputy to help with the workload and cover for any absences you might have.

I have worked in two different types of programs in the $300m to $500m range. One was global, one was domestic. One of them included individual PMs as part of the PMO; the other just included the key PMO functions and did not include the PMs in the team. My experience leads me to believe that the former – PMs as part of the PMO team – is preferable, so I will use this assumption for the rest of this article.

Let us look at the makeup of the PMO for a major undertaking. Apart from the management and administrative people, most major programs could warrant a full time quality manager, risk manager and schedule manager. You could have someone responsible either full time or part time to manage change. This could include changes within the PMO, but also possibly management of change within the company where introduction of the end result of your program may affect organization, structure, personnel and processes. In other words, they would manage what needs to be changed outside of the program to enable the expected and required result to be effective. You might also assign someone to manage program reporting.

Quality Manager’s Role
This is the person responsible for creating the program plan detailing quality, which could include:

  • Policy
  • Metrics
  • Assurance
  • Control
  • Audits
  • Internal and external standards to be met
  • Common tools and applications to be used – type and version/rev level
  • Method of updating of common tools and applications
  • Archiving policy

The quality manager would try to ensure consistency across all projects to give the program a common look and feel, and plan and manage regular quality reviews/audits throughout the life of the program to ensure the quality plan is being followed by each project. They would also ensure the defined metrics are being measured and reported as defined in the quality plan.

Risk Manager’s Role
This person would be responsible for working with individual PMs to identify and quantify risk on each project, highlighting those that need further effort to minimize risk at the project level, and assess any risks to other projects or the overall program by any one or more individual project risks. The risk manager would attend project level risk meetings and take the high level view on threats (or opportunities) at the program level, implementing risk reduction measures as appropriate. This person would be responsible for coordination between individual projects where appropriate.

Scheduling Manager’s Role
This person would work with individual PMs to ensure they had a schedule at the correct level of granularity, with critical path identified and processes in place for regular updating. They would then amalgamate these plans into a program level schedule at the appropriate level of granularity. This should then identify the critical path through the program showing which projects, or deliverables within a project, are on the program level critical path. This is key for the PMO to know, manage and review on a regular basis. The risk and scheduling managers would need to work very closely together, as any identified time risks can be monitored closely between them, particularly for deliverables/activities on the program level critical path.

Reporting
Reporting may not be a full time position in the PMO but it is a very important one. I was asked to create a reporting system for a major PMO and I designed a three-level reporting system. Each project completed a project level status report which was sent to the PMO on a weekly basis. These were rolled up and a PMO level report was created, automatically hyperlinking project information to a one line status report per project. Use of color was important (red, yellow, green) to identify problems where the PMO management might need to focus or work proactively to avoid or minimize impacts on the overall program.

The final layer of report was for senior management. This needed subjective judgments and assessment from the PMO so it could not be automated.

This role would also include financial reporting – actual costs to date, forecasts for future and comparison to the financial baseline/budget. This report would go to senior management so the specific information, format and frequency would need to be discussed and agreed with them.

Management of this major undertaking may depend on the size and complexity of the program but in my experience, a regular meeting of the PMO (including the individual PMs if possible) would review each project, scheduling and risk issues, changes and project issues, and resolve any conflict or interfaces between individual projects. Any potential threat to the overall program timeline, budget or deliverables can be highlighted, discussed, resolved and reported.

In conclusion, for very large projects (programs), the main PMO team could include the program manager, deputy, admin, scheduling manager, risk manager, quality manager, someone responsible for change, someone responsible for reporting and, in my opinion, each of the individual PMs. How many of these roles, and any additional roles such as external communications, security, networking, infrastructure etc., that may be required depend on the size, complexity and criticality of the program. Rather than assessing just the cost of the PMO which could be relatively high, it is more reasonable to consider the value the PMO provides compared with the cost of failure of the program due to inadequate management. Then a PMO can almost always be cost justified.

What positions have you involved in your large-scale project? What worked? What didn’t?


Evolving Professions: Project Management, Business Analyst, Business Architect

Posted on December 19th, 2012 in - Vicki Wrona, Best Practices, Certification, IT, Project Management, Resources | No Comments »

by Vicki Wrona, PMP

In the spirit of continuing my discussion of the evolution of project management, this month I will describe the evolution of various professions as I have seen it occur. I have found there are a variety of conflicting opinions here. I welcome different perspectives on this, so please share your views.

I started working in project management in the 1980s to a limited extent while working at LTV Aerospace and Defense, continuing to evolve my project management skills at American Airlines and then for clients served by my company, Forward Momentum. The profession that I fondly think of as project management has now evolved into multiple professions.

Let’s start with project management and its certification. Project managers have a choice when becoming PM certified. One of the most globally recognized certifications is the PMP® certification managed by the Project Management Institute. PMI was founded in 1969, the PMP® certification was first offered in 1984 and currently there are approximately 500,000 PMPs worldwide. The core body of knowledge is called the PMBOK® Guide (A Guide to the Project Management Body of Knowledge).

The first evolution that I experienced from project management is one that Karey Rees discussed in her post Project Manager and the Business Analyst: Who’s Who. This is the Business Analysis skill or profession, with its own certifications. Business analysts can become CBAP® certified, which is maintained by the International Institute of Business Analysts. While the business analysis skill has been recognized and developing for many years, the IIBA was founded recently, in 2003, and is the first organization to offer certifications for business analysts. The CBAP® certification is newer and is becoming more popular with currently approximately 2400 CBAPs.  The core body of knowledge is called the BABOK® Guide (A Guide to the Business Analyst Body of Knowledge).

In my experience and as Karey Rees described in her article Project Manager and the Business Analyst: Who’s Who, some organizations still expect their PMs to perform the function of the business analyst, one area of which is to define, document and manage requirements. I have often filled both PM and BA roles on a project. Other organizations have a separate and distinct career track for BAs vs PMs, often with little to no overlap.

Another, more recent skill or profession is that of the business architect. Where the business analyst is a smaller, logical extension of the PM function, a business architect role takes a larger leap, involving a wider scope and additional skills. The work of the business architect has a longer life cycle than the project manager or business analyst, encompassing the work of both the BA and the PM along with a strategic, and often sales, aspect. (Those from a project management background may relate to the business architect as a program manager who has responsibility for strategy and possibly sales, along with defining requirements and completing the project.)

Since this profession is a young one which is still being defined, there are multiple frameworks, including the Business Architecture Guild’s Business Architecture Body of Knowledge Handbook (BIZBOK™), The Open Group Architecture Framework (TOGAF) by The Open Group and the eXtended Business Modeling Language (xBML) framework.

If you are like me and have been working in the project management area at least a couple decades, you can look back over your working career and realize you did some or all three of these professions, if not in name, then in function. That is certainly true for me. How about you?

If you are interested in exploring these topics, please see our course list.

If you are interested in getting project management certified, check out our CAPM® or PMP® Exam Preparation courses.

Projects, Projects Everywhere: A Project Portfolio Management Approach

Posted on October 1st, 2012 in - Kathy Martucci, Best Practices, Constraints, IT, Portfolio Management, Project Management, Projects | No Comments »

by Kathy Martucci, PMP

Everybody’s project is this year’s priority. Everyone is a project manager. Every manager thinks her initiatives should receive major portions of the limited funding that is available these days. Every team wants Information Technology resources and assumes they will be there, no questions asked. Projects, projects everywhere; and NO ONE knows what is really going on!

It has been recognized that organizations that conduct Project Portfolio Management gain a competitive edge in their market by doing the right projects at the right times for the right reasons.  How does an organization identify, understand, prioritize and move forward to implement the right mix from the myriad of projects proposed from all different departments?  Let’s talk about this.

But let’s talk about this with the assumption that our organization (say ABC Financial Services) has a firm grasp on the company’s core goals and objectives for the near future.  Perhaps formal strategic planning has already taken place; regardless of how it got there, let’s say our company can align project proposals with corporate strategy.  The conversation about an organization that can’t do that is for another day.

How does an organization identify projects?  It may seem obvious, but a company should define what a project is and what parameters will be examined to make informed decisions about its eventual disposition.  Parameters should include: cost, scope, schedule, resource requirements and complexity.  For instance, ABC Financial Services defines a formal project as one that:

  • will cost over $100,000;
  • involves a core competency (for example, a dashboard for online clients);
  • requires a project manager, subject matter experts, technology staff and affects more than 15 end users; and
  • is of high complexity (e.g., will introduce new technology into the company).

Every manager who determines that his department’s initiatives fit these criteria is required to submit a high level project proposition for each initiative to the Portfolio Management Committee (PMC) well before next year’s project planning process.  The PMC is comprised of senior staff who understand the global, integrated needs and objectives of the organization and who can make decisions on where to expend scarce resources with a big picture view.

How does the Committee (representing the company, of course) understand the projects proposed?  A preliminary screening of the initial propositions may eliminate a percentage of them based on the project criteria above or the fact that they may immediately be deemed outside of the company’s goals. For each proposal passing the first gate, a robust business case must now be developed.  The business case is a key document; it describes the reasons and the justification for the project’s undertaking based on its estimated costs, the risks involved and the expected future business benefits and value. Managers may find that writing a good business case is a project in and of itself and may require more work than was anticipated.  That’s a good thing; a department must be willing to expend energy and resources to thoughtfully and completely flesh out and present their case.

How does the Committee prioritize the projects? Objective criteria should have been developed to guide the PMC in its prioritization of the proposals that make it through the second gate (business case). Subjectivity has no place in determining where a company should spend its valuable (and often scarce) resources.  Criteria such as value to the company (Return on Investment, larger market share, etc.), alignment with strategy, risks of not doing the project and other factors could be assigned weights much the same as a matrix developed for the evaluation of Request for Proposal (RFP) responses  is done in Procurement Management.  Those projects that fall below a certain score might be tabled for another year or abandoned altogether.

Once the Project Portfolio is developed, the organization has a good understanding of the money and human capital to be spent in the coming fiscal year and perhaps beyond.  What happens next may assist the organization in gaining that competitive edge…or not.  What does happen next?

Stay tuned.

Implementing Successful PeopleSoft Projects

Posted on September 10th, 2012 in - Kathy Martucci, Best Practices, IT, Lessons Learned, Top articles of 2011 | No Comments »

by Kathy Martucci, PMP

In this new white paper by Kathy Martucci, she discusses the lifecycle of a PeopleSoft implementation from determining if this popular suite of software is right for your organization to conducting a post mortem after the project is over. Over the last 15 years, Kathy has managed several PeopleSoft projects in the public and higher education sectors. Learn how to successfully handle these complex projects.

Forward Momentum Logo
Forward Momentum Logo