Skip to main content

PMI is Taking Over the World…!

Written by Hans Jonasson on . Posted in Articles. 3 Comments on PMI is Taking Over the World…!

How’s that for a heading? Exaggerated? Cheap shot? Maybe, but probably also with a bit of truth. Opening the PMBOK 4th edition I saw that PMI has added “Collecting Requirements” to the core processes and this immediately made me very uncomfortable. I have been in the PM business for 20 plus years and in the requirements business even longer, and I have always talked about the importance of separating the ownership of the product definition from the ownership of the project execution. The ownership of the product definition lies with the customer, or the buyer. They are the ones that must define what they want, the capabilities and functions that they are looking for in a product. The project manager represents the seller, or the developer, and as such their interest is often in direct conflict with the buyer.

Now, this does not mean that the project manager does not need to be involved with driving the project and the requirements gathering and even, in many cases when you are working on internal projects, be the person actually documenting requirements. But it is noteworthy that when the project manager acts in this capacity, they do it representing the customer organization They should be aware that they are wearing two hats and may have to develop a split personality. So while in real life this often happens, it is preferable to split the job of requirements gathering between the business analyst (or whatever you call that function in your business) for all product related requirements, and the project manager for all project related requirements. These requirements should be documented in two different documents with different ownership. The product requirements goes into the BRD (Business Requirements Document) and the project requirements belongs in the project plan.

It is also clear that the process of collecting requirements in the PMBOK 4th edition could use some enhancements. The inputs are the charter and the stakeholder register. While this may be defendable by making assumptions about what goes into the charter, I think it is noteworthy that, without a solid understanding of the existing business architecture, goals and objectives, strengths and weaknesses and much more, the collection of requirements may focus too much on the project and not enough on the business. And after all, a project that does not help the business achieve its goals is not a very good project.

So… after all the complaining, can say nothing positive? It is clearly good to focus attention on requirements. Many projects fail because of poorly defined, continually changing, and misunderstood requirements. It is great that PMI recognizes and highlights this. And there is no doubt that the project manager must be a major player in this area. Just remember that the project manager is not necessarily the best person to capture and analyze what the customer wants. After all the expertise a good project manager brings to the table is how to implement those requirements.

Good luck and challenge everything!

Optimizing Project Performance

Written by George Pitagorsky on . Posted in Articles. 7 Comments on Optimizing Project Performance

 

This is my first blog for Project Times. I am looking forward to sharing my thoughts and experience each month and engaging in a dialogue on project and program management and process optimization. The goal is to help in the ongoing work of optimizing our performance and the performance of our organizations. My orientation is influenced by systems thinking as a means for remaining objective and realistic. I promote open-minded mindfulness applied at the individual, team and organization level as means to optimize performance.


I apply a Zen-like approach, as evidenced in my book The Zen Approach to Project Management.‘Optimal’ means most desirable under the circumstances; the best given current conditions. Attaining and sustaining optimal performance is a dynamic process that takes place continuously over time as conditions change and learning from performance is transformed into process improvements. In project management, optimal performance is being able to consistently meet expectations by delivering useful, quality results within time and cost constraints while maximizing the efficiency and effectiveness of resources across multiple projects. When we take a broader view, we include the consistent realization of the benefits that motivated project performance and the ability to sustain and improve optimal performance.

Who doesn’t want to operate optimally? The real question is what time, effort and resources will you commit to do it?

Project management and performance optimization are intimately related. Project management is a process that is both a means to the ends of process optimization and a target of it. Project management (PM) operates within other processes such as product development, finance, engagement management and construction. At the same time project and program management are critical success factors in optimizing the performance of any process. Optimization implies managed intentional change and continuous improvement. These are brought about by way of projects and operational processes performed within programs.

Over the next months we will explore optimal project and program management performance. Among the factors that are critical to optimal performance are process (quality) improvement, methodology, project management, organizational change management, communication, expectations management, conflict management, decision making and problem solving, knowledge management, collaboration and leadership. These are combined with specific knowledge and experience in organization, technology, policies and procedures. The result is a complex system in which engineering must be balanced with an openness to let things evolve.

How do we address the blending of agile, lean and traditional project management? How do we manage defined processes, compliance and flexibility? How do we implement and sustain practical best practices in the project management process in a way that maximizes benefits? How do we satisfy all the stakeholders – clients, sponsors, champions, sales people, performers, regulators, etc.? These are among the questions we will address over the coming months.

Please comment to let me know what you think of the definitions and direction reflected above. For further exploration of these topics and for other resources visit www.pitagorskyconsulting.com.

Lessons Learned; Avoid the Oxymoron

Written by Kiron Bondale on . Posted in Articles. 1 Comment on Lessons Learned; Avoid the Oxymoron

We’ve all been there – you’ve just completed a significant project, you assemble the remaining members of the project team (those that are still sane), the sponsor (if one exists) and the other stakeholders (those that still like you) and you conduct a post-project review. You dutifully ask each participant to think back over the lifetime of the project (which sometimes feels like the lifetime of the participant) to elicit any useful information that could be applied to future similar projects. You capture these lessons “to be learned” in a document and archive the document (similar to the Ark of the Covenant in the first Indiana Jones movie) knowing that it will never be seen by human eyes again.

So what went wrong? Here are just a few of the challenges with the traditional approaches to lessons learned:

  • Conducting an effective “lessons learned” session at the end of the project requires that participants have photographic memories or have logged “candidate” lessons throughout the project lifetime in preparation for closeout. Both are unlikely, so only a superficial collection of lessons is possible.
  • Document-centric approaches to capturing lessons discourages project teams from searching or reviewing this valuable information when planning projects. Even if the lessons learned documents are stored in a centralized document management system, the manual effort of opening and reviewing individual documents is a barrier to their use.
  • Lessons are in many ways like risk events – if they are too general, too stale, or non-actionable, then their value (and credibility in the lessons learned process) is lost.

So what can you do to improve this situation?

  • Make it extremely easy for people to submit lessons learned and incent them to submit them over the lifetime of the project. Perhaps you can spare 5-10 minutes at every second project status meeting to capture these lessons.
  • Take a data-centric approach to lessons learned instead of a document-centric one – setup a simple online process to capture or search for lessons as individual items. Make sure that submitted lessons can be tagged with such useful information as the project description, the date of the lesson, the person that submitted it, and key words to locate them.
  • Institute a regular scrubbing process to weed out obsolete or irrelevant lessons from the lessons repository and to add clarification or key words for the valid or useful ones.
  • Add a “usefulness” flag to the lessons items (similar to the “Did you find this solution useful?” query that most product support organizations use on their online support sites) to identify the lessons that have been the most valuable and to help weed out the ones that are not that useful.

Like any other improvement initiative, applying these recommendations will take time, but as George Santayana said, “Those who cannot remember the past are condemned to repeat it.” I invite your feedback and you can reach me at [email protected]. Our website is (http://www.solutionq.com).

How to Survive a New Boss

Written by Cynthia Low on . Posted in Articles. 8 Comments on How to Survive a New Boss

Many of us will find ourselves assigned to a new manager over the next 12 months, if we haven’t already. For many project managers, used to working with different teams under different team leaders, some of the advice offered here might be familiar. However, times, bosses and team leaders change, and there may well be some new and helpful pointers here.

Restructuring a business leads to a re-organization of its people and resources. Unfortunately, getting a boss is like getting a parent – you don’t get to choose. Managers, on the other hand, do get to choose who will be on their team and the role each person will play. Surviving the downturn could mean surviving the transition to a new leader. Here are six key questions you can ask yourself, along with strategies to help you keep your job when you get a new boss.

Who is Evaluating Whom?

One thing many people forget is that they will be tested. Of course you are evaluating and testing your new boss. But that person is also evaluating you, and their opinion of you is going to have more significant consequences than your opinion of them. The first three months are a critical time; pretending you are on probation in a new job is not a bad strategy. One thing you don’t want to do is to act as if nothing has changed. Most managers make people changes within the first three to six months. How you handle yourself during this time is critical.

What Isn’t Working?

Step back from the situation and look at things objectively. If you just stepped into your new boss’s shoes, what changes would you want to make? What is not working? Which of these fall into your area of responsibility? Someone who is new to the situation will quickly see gaps and want to do something about them. Get a head start by identifying the root cause of problems and generating solutions. Take these to your boss so he or she can see you are on top of things.

How Am I Doing?

This is a time to be brutally honest with yourself. Even if you aren’t, other people will be frank in their discussions about you. How was your last performance review? Was your previous boss too hard or soft on you? How critical are you and your role to achieving key organizational objectives? What would your peers say about you? Your customers? Others in the organization? Your boss will be collecting this information while making an assessment of how you measure up. If there are opportunities for you to make improvements, be the first to raise them.

How Can I Work With You Effectively?

Every boss is different. Take time to study your manager, how she works and what she expects from you. This will help you understand her style and preferences so you can adapt to what she wants and needs. Situational leadership is a two-way street. Your boss needs to try to understand what motivates you and how you are best managed. You need to understand what your boss needs and adapt as required.

Am I On This Bus?

When a new manager arrives on the scene, some people choose to sit back and take a ‘wait and see’ approach. It can become a battle of wills. This is a dangerous game to play in the current economy. A leader looks for signals to see who is ‘on the bus’ and will make judgments about whom they can work with. If you are seen as someone who could be slow to follow, you may be seen as more of an obstacle than an asset.

How Can I Help?

While this is a stressful time for you, remember your boss is also under a lot of pressure. He is trying to learn a new area, new people, understand the goals and expectations his boss has of him. He is feeling a lot of pressure to appear credible and competent as quickly as possible. And he wants to chalk up some wins, early. What can you do to help? You might be a solid source of information and expertise and be able to help him get up to speed more quickly. You might be someone who has the ability to exert influence over your peers – how can you be a positive force? How can you help accelerate your manager’s ability to demonstrate results?

A new boss is a new day, and a new opportunity. If you treat it like getting a new job you increase the probability of surviving the inevitable review and evaluation going on around you. It might even be a chance for you to re-invent yourself.

Dr. Rebecca Schalm, who has a Ph.D in Industrial/Organizational Psychology is Human Resources columnist with Troy Media Corporation and a practice leader with RHR International Company, a company that offers psychology related services for organizations worldwide.

Improving Project Success Rates with Better Leadership

Written by Cynthia Low on . Posted in Articles. 7 Comments on Improving Project Success Rates with Better Leadership

Introduction

Factual and anecdotal evidence confirms that IT investments are inherently risky. On average, about 70% of all IT related projects fail to meet their on-time, on-budget objectives or to produce the expected business results. In one KPMG survey, 67% of the companies who participated said that their program/project management function was in need of improvement. Why? A number of leading factors for project failure were suggested by the survey, including the “usual suspects”: unreasonable project timelines, poorly defined requirements, poor scope management, and unclear project objectives. Granted, all of these factors can play a role in project success.


But are they the cause or project failure, or just a symptom of some larger issue? In this article, we will discuss that the root cause for many of these common failure points is really the ability to lead projects, not just manage them.

Leadership: Missing in Action

One would think that the proliferation of certified PMPs would have increased IT project success rates. However, given the research previously cited, this does not appear to be the case. Certainly, PMPs are cognizant of the processes, techniques and tools that should be used to manage projects and have documented project management experience. We contend that certification-the PMP-is indeed important, but that it alone is not sufficient for successful project management. Having been called on to rescue and turnaround numerous IT projects, we have had the opportunity to analyze why a project gets in trouble. As we looked at several of these troubled projects we realized that there appears to be a common link: leadership is missing in action. That is, while the project manager may be focused on what needs to be done and may well know how to do it, he or she may not be acting as a project leader. While certification is a good foundation for knowing what to do, it takes true leadership to drive complex projects to successful conclusions.

The PMI Body of Knowledge specifies five process groups for project management: Initiating, Planning, Executing, Controlling and Monitoring, and Closing. These five areas are consistent with the functions of management within an organization. Managers are responsible for planning, organizing, directing, resourcing, and controlling for the purpose of achieving organizational goals. The certified project manager should be able to demonstrate competent management of the nine PMI knowledge areas: project integration, scope, time, quality, cost, human resources, communications, risks, and procurement.

However, the ability to manage each of these project areas still may not produce successful project outcomes. Our experience on client sites for both government and commercial clients reveals that project leadership, not just management, is the critical differentiator. Project management without project leadership is likely to result in project failure.

Certainly, it is not our intent to redefine leadership. It’s already been defined as the ability to affect human behavior to accomplish a mission or the act of influencing a people to set and achieve goals. Volumes of business and strategy texts have been written about this critical competency. Check out your local book store and you will see numerous titles identifying leadership styles, leadership characteristics, and inspirational leadership topics. Some authors or practitioners have made the point that leadership and management represent two different skill sets and that either an individual has the characteristics and skills necessary for leadership or those more appropriate for management. Others have suggested that leadership is knowing where to go and that management is all about how to actually get there. We find this dichotomy troubling and perhaps at the heart of our IT project management failure rate. Instead, we believe that not only can project managers act as leaders, but in fact that they must provide leadership if projects are to achieve results.

A Closer Look at Project Leadership

Project leadership is all about shaping a team of diverse individuals (employers and contractors, some from different organizations) into a force that produces measurable project results. At our company, we recruit and develop project managers who can provide the leadership that complex IT projects require. At a basic level, project managers must be able to set the vision, define success, and determine the measurements of success. Then they must inspire, persuade, and lead the project team.

We argue that for project managers to become project leaders, they must demonstrate competence in essential skill areas. Successful project leadership involves:

  • Leading courageously
  • Influencing others
  • Acting with resilience

Leading courageously is a critical competency because large IT projects have a huge resource pool representing different organizations and job roles. These resources may see their tasks slightly differently and may not all be aligned with project goals. Furthermore, the sheer number of issues and risks may make it difficult to zero in on those tasks that are most critical. In this kind of environment, leading courageously can easily make the difference between success and failure. Leading courageously means clarifying what is important and taking a stand to resolve important issues. It also requires driving hard on the right issues and confronting problems promptly. Finally, courageous project leadership means being decisive and challenging others to make tough choices.

Influencing others is an essential competency for most projects, but especially for those with large project teams, numerous stakeholders, and different user communities. Influencing others means giving compelling reasons for ideas and suggestions and winning support from others, both within the project team and in the user and stakeholder community. It also requires the ability to negotiate persuasively and get others to take action. Finally, it means influencing the decisions of upper management, whether within your own organization or the client organization.

Acting with resilience is critical to project leadership and is especially important when projects are at critical stages or in trouble. When a project manager acts with resilience, he or she keeps the focus on project goals and refuses to give up. Sometimes it means being tough enough, in the face of adversity, to fight the good fight and get agreement on issues that threaten to derail the project. Or it may simply require being flexible enough to negotiate solutions that keep driving for the goal of project success, when others might give up and accept defeat.

Summing It Up

In this article we’ve presented the case that project leadership is the differentiating factor in project success, especially on large, mission-critical projects. Knowing what to do and being able to manage the nine knowledge areas identified by PMI is not enough on complex projects.

Successful project managers must lead courageously and be able to influence others to resolve some of the most critical problems that projects experience. And to paraphrase Churchill, they must never, ever give up; they must act with resilience even in the face of conflict and problems. To experience the project success that investments demand, assign project managers who can act as project leaders to your mission-critical IT projects.

Dr. Karen McGraw is the founder, Chief Knowledge Officer, and past president of Cognitive Technologies. Dr. McGraw has extensive experience in technology-based performance improvement solutions ranging from the design and implementation of computer-based learning and learning management systems, to expert systems, performance support systems, intelligent interfaces, and knowledge management systems. Dr. McGraw is a co-developer of the Performance DNA toolkit for analyzing human performance to diagnose improvement opportunities. Dr. McGraw is nationally recognized in eLearning, knowledge acquisition, scenario-based requirements, and performance analysis and design and has authored five texts, including User-Centered Requirements and Knowledge Acquisition: Principles and Guidelines.