Skip to main content

Author: Robert Wysocki

OUTSIDE THE BOX Forum: Fixed Bid Agile Projects

Written by Robert Wysocki on . Posted in Articles. 3 Comments on OUTSIDE THE BOX Forum: Fixed Bid Agile Projects

It would seem that this is like mixing oil and water. But it does work with just a minor adjustment of client expectations.

In the traditional project management world, the sponsor provides the resources on the assumption that the project manager will deliver a specific product that meets the stated functional specification within the resource constraints and that satisfies expected business value. In the complex project world, the sponsor is asked to provide the resources without any statement of what the deliverables will be and even if they will satisfy the desired functional specifications and provide the expected business value. You are asking the sponsor to invest resources with no assurance they will get anything that meets their needs and produce acceptable business value. These are always high-risk projects that may have been unsuccessfully tried before. On the face of it that doesn’t sound like a good business proposition.

Let’s dig a bit deeper into the realities of these complex situations and see how the project might be presented to the sponsor as a good business proposition.

What Kind of Projects Are We Talking About?

First, they are risky projects. They will be critical to the continued success of the business but will not have been successfully executed in the past. I recall the first time I encountered just such a project. I think you will find its story interesting and that it offers a clue to the strategy you can use should you be faced with this situation.

Over 25 years ago I was approached by a loyal client who wanted my team to build a complex application whose goal was an ideal end state (or maybe a dream state to be more accurate) for their business model but how to achieve it (its solution) was mostly undefined. The project had been tried in the past without success. The client was willing to invest $5M but needed a solution within 12 months. I could choose my team. The continued success of their business was threatened by technology and new competition and depended on the success of this very high-risk project. I told my client that we would do the project if he would appoint one of his senior managers to our team. They should understand the business model requirements and be able to represent and make decisions for their business. I would want that manager to join our team as a full-time member. I argued that I could not assure success unless the client provided that level of commitment. The manager was appointed, and the project was a success.

I learned two invaluable lessons from that experience. The first lesson eventually evolved into our Co-Manager Model. I have never taken a client project engagement since then without using this Model. Over the years the Model has matured and become an essential tool for my version of Collaborative PM. It has become pervasive across several project management processes which are topics for other articles.

The second lesson was a strategy for contracting such projects, and that is the topic of this article. You need to approach the sponsor with a statement that the project is complex and high risk and you want to do the best job you can and hopefully deliver the expected business value with a solution that meets the specified requirements. Others have failed, and there is no guarantee that you will be successful. So your proposal goes something like this:

This project is very high risk and critical to the continued success of your business. I want to assemble the best team I can so that I can do the very best job possible. With the appointment of a senior manager from your business unit to my team who can make commitments and decisions for you. We will work as co-equals to produce the very best solution we can given the assigned resources and time frame you offered.

Granted this will take the sponsor out of their comfort zone because they will be making an investment without any guarantee of a return. But their efforts have failed so far. So what do they have to lose? Except for their business which will be lost unless a solution can be found. Fast forward to the end of this project. You will produce at least a partial solution but will have learned a lot about the problem situation and should have several potential directions to go to improve that solution. Another investment will have a better return and perhaps provide the complete solution too!

What Is to Be Gained from That Senior Manager?

The key here is that that senior manager works as a co-equal with the project manager. That creates ownership of the deliverables, and with their reputation at stake, they will do their best to make sure the project is successful and delivers the expected business value. So as a project manager you will get their best effort. All you have to do is cultivate that collegial relationship. One thing you will need to keep in mind is that you are taking the client outside of their comfort zone when you recruit them as your co-manager.

Putting It All Together

We are in the Information Age where project teams are no longer command-and-control teams. They are collaborative teams. Collaborative teams are groups of people who are working together for a common goal. Each team member brings their expertise to bear on the project. Team expertise is an excellent risk mitigation strategy!

OUTSIDE THE BOX Forum: Imbed Continuous Process Improvement in the Project

Written by Robert Wysocki on . Posted in Articles. 8 Comments on OUTSIDE THE BOX Forum: Imbed Continuous Process Improvement in the Project

We started the project with a three phase Framework (Ideation, Set-up, Execution).

As the project moved through these phases, we found the process and product improvement opportunities that might be applied to the Framework and even folded back into the project from whence they came. Before this, our process improvement efforts were all made post-project. The motivation and benefits have been better with the embedded approach.

This article introduces an entirely new way to think about process and product improvement programs. It is not an after the fact assessment. Rather, it is conducted along with the project, and its results factored back into the project as appropriate. Plus, it is the first application of the Declaration of Interdependence for process improvement to reach the public forum.

Background

wysocki 052917 1

Our Framework is shown below in Figure 1.

Figure 1: The three phases of the ECPM Framework

This three-phase framework has several features that allow for maintaining the adapted PMLC Model to the changing profile of the project. Among those features is an embedded Continuous Process Improvement Program shown in Figure 2 below. The Program is based on the Declaration of Interdependence (Source: The Declaration of Interdependence (2005 David Anderson, Sanjiv Augustine, Christopher Avery, Alistair Cockburn, Mike Cohn, Doug DeCarlo, Donna Fitzgerald, Jim Highsmith, Ole Jepsen, Lowell Lindstrom, Todd Little, Kent McDonald, Pollyanna Pixton, Preston Smith and Robert Wysocki. www.pmdoi.org). To achieve this business value, we draw upon the values expressed in the DOI. The 15 authors of the DOI are a respected group of project management consultants and trainers who have earned the right to speak. Their contribution will be seen as a major contributor to our understanding of the critical role that Patterns can play in the successful execution of complex projects.

The six principles of the DOI capture the essence of an effective complex project management environment. Underlying these principles are three necessary and sufficient conditions:

  • Each principle is critically important
  • Each principle captures a new and innovative management concept
  • Each principle captures the operating framework of its authors

The six principles of the DOI are:

  • We increase return on investment by making the continuous flow of value our focus.
  • We deliver reliable results by engaging customers in frequent interactions and shared ownership. 
  • We expect uncertainty and manage for it through iterations, anticipation, and adaptation. 
  • We unleash creativity and innovation by recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference. 
  • We boost performance through group accountability for results and shared responsibility for team effectiveness.
  • We improve effectiveness and reliability through situation-specific strategies, processes, and practices.

wysocki 052917 2

Figure 2: Imbedded Process Improvement Using the Declaration of Interdependence

Since its publication 12 years ago the DOI has become the Call to Action for assessing the complex project management landscape and is now the best descriptor we have for the hyper-performance end state of project management. It is the foundation on which the ECPM Framework continuous process improvement program is designed and evaluated.

MEASURING THE EXTENT OF DOI IMPLEMENTATION

To date, there has not been a set of metrics that describes the extent to which a project management model has achieved the DOI End State. In fairness, that DOI End State is a continuous journey rather than a destination to be reached. In defense of not having such metric(s) is that a DOI environment does not lend itself to quantitative assessment. That must be corrected if we intend to implement a continuous process improvement program for DOI implementation. In the absence of a quantitative metric, a surrogate must be defined so that progress towards that DOI End State can be measured.

As the ECPM Framework evolves through both customization to meet the specific needs of an organization and through the results of the continuous process improvement program contributions to DOI realization will occur. Additionally, improved DOI realization will result in an increase in delivered business value and improved project success. Quantitative assessment of those improvements is not likely to be correlated with any specific DOI but rather attached at the project level. Qualitative assessment at the DOI level may be the only reasonable expectation. Let us take each DOI principle separately and see how we might make those assessments with a set of quantitative metrics.

  • We increase return on investment by making the continuous flow of value our focus.Return on Investment is a direct measurement of incremental business value delivered. The incremental business value may be the only quantitative metric we have, but the delivery of that value may well stretch out over a long time frame. Incremental business value can be measured, but it may not be available in a timely manner for use in the continuous improvement program. Early estimates may be made however. To be useful as a measure of the flow of value, we need to think in smaller increments. For example, every task that contributes to the delivery of a solution requirement adds value to the then updated solution. That suggests some primitive Earned Value may provide a measure of incremental value over time. Tasks are work embedded in activities and activities are work packages embedded in a cycle build plan. So the number of tasks completed against the number of tasks in the cycle plan gives us not only a measure of the flow of value but also a measure of effectiveness and efficiency.
  • We deliver reliable results by engaging customers in frequent interactions and shared ownership.
    • Adjacency diagrams may be useful. What data is needed; how is it analyzed, and how is it graphically presented?
    • The degree to which clients participate. This is a subjective assessment. Tracked over time, it is a measure of improved interactions and shared ownership.
  • We expect uncertainty and manage for it through iterations, anticipation, and adaptation.
    • Probative vs. integrative swim lane frequency tracking and trend analysis. To dig a bit deeper consider the percentage of Probative Swim Lanes that result in some increments being added to the solution. Alternatively, better still what are the percentage of 2nd attempt Probative Swim Lanes that result in some solution increments. How about the 3rd attempt? Somehow these trends are a measure of the improved effectiveness of the Probative Swim Lane process. You see the pattern emerging.
  • We unleash creativity and innovation by recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference.
    • Observing participation in brainstorming sessions and problem-solving
    • Link between the process manager and the product manager
    • Client generated scope change requests vs. developer generated
    • Client participation in brainstorming sessions
  • We boost performance through group accountability for results and shared responsibility for team effectiveness.
    • Relative frequency of I, You and We in conversations.
  • We improve effectiveness and reliability through situation-specific strategies, processes, and practices.
    • PMLC Model adjustments and changes.

Putting It All Together

In practice, I have not used the project team to conduct the assessment. I have commissioned a small team from the PMO to conduct it. Their objective is a fair and unbiased assessment with minimal demand on the project team.

OUTSIDE THE BOX Forum: On Changing Horses in Midstream

Written by Robert Wysocki on . Posted in Articles. 3 Comments on OUTSIDE THE BOX Forum: On Changing Horses in Midstream

We started out using Scrum but as we learned more about the solution we have had to adapt Scrum to the realities of the project and its environment.

After so many changes our project management model is held together by bubble gum and hairpins. It is very inefficient and ineffective as well. We are right in the middle of the project, and the solution is now known. All that is left is to build and deploy the solution.

I contend that there are situations in Complex Project Management where changing PMLC Models during project execution will be a good business decision. So for the above example, should we abandon Scrum in favor of a more traditional model? What factors should we consider in making that decision?

The Situation

The Complex Project Landscape is one where either the Solution or the Goal are not clearly defined or understood at the outset of the project. Through iteration, the deliverables converge on the final Goal and/or Solution. Then there is the acceptance of the deliverables, and that is measured by delivered business value compared to planned business value. Obviously, these are high-risk projects. It is what happens during the execution of these projects that is my interest here. First of all learning and discovery will have taken place and perhaps after some number of iterations the Goal is known (you chose an Extreme Model because the Goal was not clearly defined at the outset) or the Solution is known (you chose and Agile Model because the Solution was not clearly defined at the outset of the project). Your team is not experienced in the Model you chose originally and would be much more effective if they could switch to a more Traditional Model.

The Factors

Such a change may sound simple but let’s consider some of the factors that we will have to deal with if we decide to change PMLC Models.

Cost

There are three costs to consider:

Cost of abandonment – This will include documenting the current status of the project if a new team will be brought on board. Any contracts that may not be carried forward and will have to be closed will also be added to the cost. If any deliverables produced so far will not be part of the final solution, there are sunk costs to be added.

Cost of creating the new plan – These are labor costs and facility costs that would not be otherwise incurred. In some cases, these costs will be offset by iteration planning costs that would have been incurred using the initially chosen model.

Cost to execute the new plan – These costs will have to be compared to the cost of executing the original plan

Schedule

Most likely the time to re-plan the project will have to be added as will the time to execute the new plan as compared to the time to execute the original plan. If there are changes to the team composition, the availability of those new team members may adversely affect the new schedule.

Team Composition

The skill profile of the new team may be different from the skill level of the original team. Project team membership should be expected and the need for hand-off documentation identified.

Scope Change

There is still the possibility that scope change will affect the new plan going forward, but at least the deliverables and expected business value will have been defined.

Benefits

Following an agile or extreme methodology leaves open the final deliverables and the business value that will result. Following a traditional methodology removes those uncertainties and gives sponsors and executive management a criteria for portfolio decision making. That is more in their comfort zone.

Putting It All Together

This is not a definitive analysis because that is not possible without a specific project situation to consider. Rather, I hope I have defined the factors that must be considered when making a decision to change PMLC Models in mid-project. It is a complex decision with multiple criteria to consider. In my experience, the decisions have ranged from no-brainers to complex. There will be evidence supporting the change and evidence for no change. There will be intangibles too. For example, the team may have established momentum and what value do you place on that? The simple gut feel of the team may be the ultimate decision criteria.

OUTSIDE THE BOX Forum: Certification is Based Only on Vetted Experiences

Written by Robert Wysocki on . Posted in Articles. 4 Comments on OUTSIDE THE BOX Forum: Certification is Based Only on Vetted Experiences

There was a time that in order to become a member of the British Computer Society (BCS) an individual had to validate competency at what was defined as an entry level professional.

That level was reached after about 4 years of increasing practice and responsibility under the guidance, management, and vetting of a BCS member. It was they who approved an individual for BCS membership. Much like an apprenticeship would work. Once approved for membership the individual was now a card-carrying professional with all of the pomp, circumstance, and responsibilities attached.

I had the opportunity to be a consultant to the BCS during the formative years of their Professional Development Scheme (PDS) and can personally attest to its rigor. Those who held the vetting responsibility took their role seriously. The PDS was based on an Industry Structure Model (ISM) that defined 64 job functions defined at 9 levels of competency. 29 of the 64 roles are defined at the professional level only. A total of 245 roles populated the model. 168 of the 245 roles were professional level status. Project Management was defined at 5 professional levels beginning at Level 4, the beginning professional level and extending through level 8, the director level.

There were feeble attempts to bring a version of that program to the US under the sponsorship of the Data Processing Management Association (DPMA) but never was treated seriously. That was in the 1990s, but I never forgot the experiences and what I learned from the BCS regarding competency assessment and validation. I always thought that the BCS program could be adapted to project management.

Below is an adaptation of the BCS Industry Model for your consideration. It can easily be aligned with project management.

Level 0: Trainee

This is the base entry level in the profession for those with minimal qualifications. They are often direct entrants from the secondary education system and may not have previous work experience.

Essential Characteristics

  • Operating within a structured and closely supervised environment.
  • Participating in a planned program of training and experience acquisition.
  • Following initial training can function effectively across a limited set of routine tasks.
  • Possesses basic oral and written communications skills.
  • Is capable of learning new processes and applying newly acquired knowledge.
  • Demonstrates an organized approach to tasks and the ability to produce required results.

Level 1: Technician

This is the standard entry level to a role. It is often the appropriate level for adequately educated trainees.

Essential Characteristics

  • Operates within a structured and routinely supervised environment.
  • After initial training uses methods, procedures, and standards applicable to assigned tasks with less frequent need for direct supervision.
  • Demonstrates a rational and organized approach to tasks.
  • Has developed sufficient oral and written communication skills for effective dialogue with colleagues and superiors.
  • Is able to absorb and apply new technical information rapidly when it is systematically presented.
  • Within a short time horizon, is able to plan, schedule and monitor own work.

Level 2: Senior Technician

The lower of two levels for those who are familiar with the scope of their tasks but who do not carry supervisory or team leader responsibilities.

Essential Characteristics

  • Operates within a supervised environment with frequent review of tasks.
  • Is familiar with, and uses as directed, all applicable methods, procedures, and standards.
  • Is able to function effectively across tasks within scope using available tools, methodologies and/or equipment, with only infrequent reference to others.
  • Is able to demonstrate effective oral and written communication ability covering all routine activity and contacts.
  • Is able to rapidly absorb new technical information as required.
  • Demonstrates a systematic, disciplined and analytical approach to problem-solving.
  • Has acquired an appreciation of the wider field outside his/her own specialization and has developed a good broad understanding of the discipline.
  • Within a limited time horizon, is able to plan, schedule and monitor own work completely.

Level 3: Associate

The upper of two levels for those who are familiar with the scope of their tasks but do not carry supervisory but may have team leader but not project management responsibility. It is distinguished from Level 2 by the depth and complexity of the technical knowledge base covered and the extent to which supervision is required. Level 3 implies a high degree of accountability for self-controlled work. It may include a guidance role for the less experienced colleagues.

Essential Characteristics

  • Depending on the scope and complexity of the work operates within a largely unsupervised environment but within a clear accountability framework.
  • Is familiar with, uses effectively and can select appropriately from applicable methods, procedures and standards.
  • Is able to function effectively, productively and meet time and quality targets across tasks within scope using available tools, methodologies and/or equipment with reference to others only by exception.
  • Can assume team leader responsibilities for the work of less skilled professionals .
  • Demonstrates both formal and informal communications ability; orally and in writing, when dealing with all colleagues and clients.
  • Is able to rapidly absorb new technical information as required.
  • Demonstrates a systematic, disciplined and analytical approach to problem-solving.
  • Has a good appreciation of the wider field outside his/her own specialization and has developed a good broad understanding of computer systems and techniques.
  • Understands how the specific role relates to the relevant are of employment, to its clients and to the employing business as a whole.

Level 4: Senior Associate

Level 4 will normally be achieved after clear evidence is available of full competence in a specialized role. At this level, full technical accountability for work done and decisions made is expected. The ability to give technical or team leadership will have been demonstrated as well as a high degree of technical versatility and broad industry knowledge.

Essential Characteristics

  • Takes responsibility either for substantial technical decision-making or for teams of staff. If the latter demonstrates the basic qualities associated with team leadership and project management.
  • Is thoroughly familiar with the available tools, methods, procedures and/or equipment associated with specialization. Possesses adequate technical depth to make correct choices from alternatives in all these areas.
  • Is able to apply selected tools and techniques in such a way as to meet set targets of cost, time, quality and performance.
  • Is able to communicate effectively both formally and informally with all those with whom working interfaces arise whether they be colleagues, clients or customers.
  • Shows initiative and makes time available to ensure general competencies are up to date in line with the development of the individual.
  • Possesses a clear understanding of the relationship of any specialized role to the context in which the work is carried out. More generally, this understanding applies to the employer’s business and the needs of those who will use the end product.

OUTSIDE THE BOX Forum: A Higher Order View of Project Management

Written by Robert Wysocki on . Posted in Articles. 2 Comments on OUTSIDE THE BOX Forum: A Higher Order View of Project Management

Project managers have been fixated on the PMBOK. The number of PMPs and the popularity of training programs to help project managers pass the certification exam is testimony…

but PMBOK is only a small but necessary part of this story. Open your mind to the following possibility.

In the complex project landscape, the most effective project management approaches will be ones that are flexible, and that will be determined by:

  • the characteristics of the project
  • the organizational environment
  • the external market situation

All three of these are dynamic, and when any one of them changes, the project management approach might also change. The objective will always be to maintain the alignment of the project management approach to the project in order to achieve maximum business value and minimization of the risk of project failure. In other words, projects are unique and so should the best fit model for managing them also be unique. That is suggestive of a higher order view of projects and project management that has not been developed by the project management thought leaders. That is, not until the business model introduced here came to be.

The Characteristics of the Project

That higher order view of projects is a four-quadrant landscape of project types as shown below.

wysocki 040617 1

Figure 1: The Complex Project Landscape
These four quadrants define projects that are very different and that require very different management approaches. But know that these approaches will draw heavily on the 5 Process Groups and 10 Knowledge Areas of the PMBOK.

  • Traditional Projects
    For these projects, both the goal and solution are clearly known and completely defined at the outset. A WBS and project schedule can be developed and used to manage the project effectively. Few changes are expected. Life could not be simpler.
  • Agile Projects
    For these projects, the goal is clearly known and completely defined but how to achieve it (the solution) may be almost completely known, partially known, or hardly known at all. A WBS can’t be generated nor can a project schedule. These projects are managed in iterations where each iteration is designed to learn and discover missing pieces of the solution. Hopefully, all the missing pieces can be discovered before the time or budget runs out. These a higher risk than the Traditional Projects and an acceptable solution may not be found.
  • Extreme projects
    For these projects, neither the goal nor its solution is clearly known at the outset. R&D projects are usually typical of these projects. These projects are also managed in iterations where each iteration is designed to learn more about the goal and possible solutions. The results usually reduce the scope of the goal and identify possible solution paths for the updated goal. In the end, the goal and solution converge.
  • Emertxe Projects
    For these projects, a solution to some problem exists at the outset, but the goal to which they align is not clearly known. The project is done in iterations where each iteration is an attempt to discover or define the goal. The resulting deliverable goal may or may not have business value.

The big question is where does your project fall in these four quadrants?

The Organizational Environment

Management can entertain all sorts of new business opportunities, and envision processes and practices that work perfectly. Someone has to pay attention to the ability of the enterprise to deliver on these dreams. In most organizations, human resource capacity, among all other resources, usually happens by accident rather than as the result of a human resource management system that aligns resources with the strategic plan of the organization.

Market opportunities can only be exploited within the capacity of the enterprise to support them. Two of the big questions for senior management is how to spend current enterprise resources for maximum business value, and how to grow those resources to align with future strategic portfolios.

Enterprise capacity is both a constraining factor and an enabling factor. As a constraining factor, what the enterprise should do is limited by what the enterprise can do in the near term, and finally, leads to what the enterprise will do. As a counter measure to the constraining factor, the enterprise needs to assure the alignment of not only resource supply but also resource availability against the business demands for those resources. So enterprise capacity is a dynamic tool that can be adjusted as a deliverable from the planning exercises. Expanding or enhancing resources will reduce the schedule contention between resources, but that is a business decision that arises during the fulfillment of the strategic plan.

As an enabling factor, resource managers collaborate with functional business managers and line of business (LOB) managers to creatively solve resource availability problems and enable the exploitation of new business opportunities. These collaborative efforts result in the commissioning, scope revision, rescheduling, postponement, and termination of projects, programs, and portfolios. This is the reality imposed by the ECPM. We have no choice but to deal with it!

The External Market Situation

The feeding frenzy that has arisen from the relentless advances of technology and the Internet has had several disruptive effects on the business climate. These effects are global and have unknowingly put many businesses in harm’s way. The Internet is the gateway for anyone, anywhere to create and sell their products and services! Business sustainability now depends on how effective a business can erect barriers to entry for new competitors, and how it can “out create and outpace” the competition. Anyone, regardless of their physical location, can be a competitor. Even if you don’t sell in the international markets, your competitors can and do, so you are pulled into the global marketplace and may not even be aware of it. Your business decisions must consider actual and potential global impact.

Market opportunities will come and go, and not on a schedule that organizations can predict or even be able to accommodate. Whatever project environment your organization embraces, it must be able to respond immediately. The opportunities can be internal (problem-solving and process improvement to maintain or improve market position, for example) and external (new product, service, and processes for meeting the needs of an expanded customer base, for example).

The Higher Order View of Project Management

That higher order view of project management is captured in the 3-phase model:

  • Ideation Phase
    • What business situation is being addressed?
    • What do you need to do?
    • What will you do?
  • Set-up Phase
    • How will you do it?
  • Execution Phase
    • How will you know you did it?
    • How well did you do?

Embedded in the Ideation Phase are such activities as Brainstorming, Business Cases, and Requirements Elicitation. Embedded in the Set-Up Phase is PMBOK and the portfolio of project management life cycle (PMLC) models to which it applies (Traditional, Waterfall, Incremental, Prototyping, Scrum, FDD, PRINCE2, DSDM, etc., etc.). Embedded in the Execution Phase are 5 processes: Define, Plan, Build, Monitor Control and Close.

The ECPM Framework that drives all of this is shown below in Figure 2.

wysocki 040617 2

Figure 2: The ECPM Framework