Skip to main content

Project Management in a Technical Environment

Written by Cynthia Low on . Posted in Articles. 5 Comments on Project Management in a Technical Environment

In today’s world of ever increasing speed, complexity and competitiveness we as technicians and managers find ourselves with the overwhelming need to achieve absolute efficiency. This need forces us to organize and direct our energies in more creative ways. As we surpass one goal, another sets the bar even higher requiring additional improvements. This efficiency is generally a result of taking our experiences and lessons learned and converting them into an improved method or product at the most competitive cost.

Project management helps bring efficiency to our technical challenges. Originating in the days of pyramids and castles, project management has advanced through NASA and the Space Program onto modern construction processes and into the worlds of IT and manufacturing. PM is achieving a maturity in virtually every industry requiring products or deliverables. In many organizational environments, the term program management is used to define the management and prioritizing of a multiple of projects, not to be confused with project management.

At some point in our careers we have all been involved with, been made aware of, or practiced the principles of project management. It is largely defined as the process whereby you are called upon at the inception of a project or deliverable, to plan, co-ordinate and control all the resources required to complete the project or deliverable through to operation within an allotted time, an agreed budget and to a specific level of quality and safety, at a minimum of risk.

In the early stages of our careers or as specialists, many of us play a role in the overall project management process. A project team may have participants exhibiting planning skills; other members of the team may have more technical or quality skills. Generally one individual acts as the project manager, overseeing the entire process and holding ultimate responsibility and authority. It is human nature to appoint a leader. This position is usually achieved after years of playing several roles in the PM process, gaining knowledge and experience or through formal education. Occasionally a project manager is assigned this duty at a premature stage in his career development, which can produce less than acceptable project results. It can also leave the project manager disillusioned and wrongfully perceived as an underperformer when, in fact, a lack of skill sets was the true culprit.

There are countless volumes of literature available to help detail and define the need and application of project management techniques and methods. Many organizations have adopted PM principles and created procedures for their own unique circumstances.

In this article, I wish only to highlight the basics of PM and how it relates to our daily work assignments as participants of a project team.

Why Use Project Management?

As with any task, it makes good sense to create and follow a well thought out game plan. PM helps create that plan. It helps you focus on your objectives by documenting your requirements and building your deliverable on paper before committing expensive and scarce resources to it. PM produces information which increases your level of confidence and communicates the expectations. It forces you to plan your resources, and then use them efficiently and productively.

The Project Management Institute, founded in 1969, is the custodian of The Project Management Body of Knowledge. This document represents years of effort and standardization in the profession of project management. Through education and practice one can achieve the recognized designation of PMP. (Project Management Professional)

Projects can range in size and scope from a new product such as a pipe fitting to a major industrial construction project such as a nuclear plant. Each deliverable has its own unique set of circumstances. They can be standard products with multiple quantities or, as in many cases, a custom application. Regardless of how unique the project is, in general all undertakings require some form of control and organization.

Project Management is made up of many organizational competencies, however, we will deal with the following six main controls which, once mastered will deliver a high incidence of success. These are not in order of importance or significance. Each unique project will have a set of circumstances that will dictate what priority this list should follow.

  1. Scope
  2. Time
  3. Cost
  4. Quality
  5. Resources
  6. Safety

1. Scope

A scope of work defines what it is you want in detail through written documents or an electronic data base. It further serves to avoid interpretations. A well defined scope provides clear instructions understood to mean the same thing by all who are affected by it. The Product Scope is the “What” and the Project scope is the “How”. A scope can also help to define the work breakdown. The work breakdown reduces the scope or project to easily definable and manageable parts that can be resourced and scheduled. The scope of work or a work breakdown is specific, measurable, attainable, realistic and constructible. Tender documents generally begin with the scope of work. It should address all the major aspects of a project such as time, cost, quality and safety. Generally, the more detail found in the scope of work, the more efficient the cost and time will be in executing it.

2. Time Control

Schedules are created to plan, monitor and control that precious commodity, time. The scope of work is usually accompanied by a time restriction. This can be in a macro form or a more detailed micro form. Several forms of time control exist. The worst form of time control being memory or, as many of us veterans recall, on the back of a cigarette pack or napkin. More effective methods include lists with dates, day-timers and notes. Modern software now allows us to utilize time-scaled charts, specialized computer applications and risk analysis programs.

In essence, time control involves establishing a timeframe or duration and applying it to an item of work breakdown or activity. It should be measurable so that at specific intervals progress can be determined against the base or original plan. These durations are assigned by the use of actual data from previous results or from estimated results. These activities are linked to other activities via dependencies. These dependencies are called relationships. Activities can be linear or in series or they can be parallel with one another. By creating this network of interdependencies, a critical set of activities emerges which helps to determine priorities. With accurate input of actual progress, the schedule acts as a tool to determine current status and predict future results.

3. Cost Control

Similar to time control, cost control assigns value to the scope of work. Individual items within the scope can be valued and then summarized to a work breakdown item or cost code. Ideally, time control and cost control should support the same basic work breakdown structure thus providing a basis for measurement. This basis serves as the initial cost plan. The value or cost of an item of work can be determined by using historical data, estimated results or through research analysis. Cost is generally broken down into labour and material with possible contingencies, where they apply.

Controlling costs involves careful procurement and assignment of resources and materials within the scope budget or estimate. Any deviation from the scope or changes in work is a major source of cost overruns. Change management becomes a key function in controlling these unplanned costs. Comprehensive documentation is the basis of a well managed cost and change control program.

4. Quality

Quality can be defined as the ability of features and characteristics of a product or service to satisfy stated and implied needs.

This takes a more technical approach to the management of work and the level of expectations in product or process. A good quality program starts with a well defined need through clear and concise scope documents, specifications and drawings. It includes such factors as material specifications, dimensioning, tolerances, welding procedures, codes and regulations. In the case of personnel it involves levels of skill, expertise or, certification and professional designation. Quality programs should be recognized and uniform. Many organizations have adopted recognized international standards of quality control such as ISO. Quality involves inspections and the documentation of results which are compared to the specified needs, which may in turn lead to non-conformance and corrective actions. Needless to say the fewer non- conformances encountered, the more successful the project in terms of cost and time.

5. Resources

Resources include all the elements required to execute or deliver the project such as labour, material, money, equipment, tools and time. It involves procuring and assigning these resources at the point of need in the project in order to avoid waste or delay. Resources introduced too early, too late or inadequately become inefficient or non- productive thus driving cost and time beyond the plan or budget. The key to efficient use of resources is to determine the optimum quantity and apply them at the optimum time.
Procurement of resources, managing, human and labour relations also become key functions in a project in order to ensure adherence to quality, time and cost. Resources too can be planned in the same manner as cost and time applied to items on the schedule. By applying resources to the schedule, histograms and cumulative curves are generated, providing early resource management capabilities.

6. Safety

As a mature, industrialized economy and society, we have developed safe-guards to ensure that people can work at their vocation with a level of confidence in their personal safety. Today, unfortunately, there continues to exist economies which lag behind in basic worker safety practices. Eventually education will help to create a global minimum safe work standard.

The goal of a safe project is to perform and complete the scope of work within a specified time, cost and quality without injury or incident. This begins with a complete safety policy and procedure. The policy and procedure adheres to or exceeds government regulated standards of safety. These policies and procedures must be communicated to all the project participants via several media methods. These include orientation, training, regular reminders, visual and audio awareness techniques. Safety records and reporting are an integral part of a good safety program which generates statistics and lessons learned, thus injury avoidance. Safety audits to ensure compliance are a must as complacency can easily result in an injury to a worker. Another widely used safety technique is the task plan which documents the task process and highlights the potential dangers, and the techniques used to avoid or reduce the risk of injury. Each participant in the task reviews the documented plan and acknowledges his understanding prior to the work. This communication helps to unify the group’s responsibilities and identifies the expectations.

To achieve a competitive edge it is necessary to take an organized approach when embarking on a project. Project management can help to achieve that success by providing techniques and guidance through each stage of a project’s development. Each of the above controls does not act alone. They each relate to one another in a project. If one of the controls is not managed adequately it will manifest itself on some other control item. For instance, a badly defined scope will increase costs and duration due to excessive contingency allowances. A poorly executed safety program can result in serious injury which produces emotional and tragic results but also causes resource inefficiencies and increased costs or time delay. Conversely poor quality or product can force a project into reworking non-conformances utilizing additional unplanned resources.

In conclusion it makes good sense to consider the fundamentals of project management in your assignment. When a project is small in nature a project manager may be on their own to perform all the major functions of control. On larger projects the function of the project manager may be as leader and coach guiding a team of experts. Utilization of project management does not guarantee perfect results in all cases. If applied and executed properly, project management will reduce the risk of failure and increase the rate of success as you gain confidence and experience from project to project.

 

Robert Mattia’s 30 year career began as a Planner/Scheduler advancing to Project Manager in engineering, fabrication and construction companies, covering projects in steel, paper, wood, manufacturing, automotive, chemical, power, gas and mining industries in Canada, USA and UAE. He teaches part time. He graduated from Ryerson Polytechnical University with a Project Management major is an A.Sc.T. (OACETT) and is Certified in Alternative Dispute Resolution. Robert can be reached at. [email protected].

Different Types of Projects from Small to Distressed

Written by Cynthia Low on . Posted in Articles. 6 Comments on Different Types of Projects from Small to Distressed

Editor’s Comments

In this Project Times we take a look at a wide range of projects and examine some of the difficulties and complexities involved in different projects. Happily, our contributors offer good advice for solving some of the project problems we’re likely to stumble on. Our bloggers take a look at risk management and whether the PM needs to be onsite to be effective. You might also want to visit the Project Times Bookstore and check our Calendar for upcoming events.

  • Recovering Distressed Projects (part 1 of 2). Contributor, Tom Flynn, is concerned that more and more he hears the word “distressed” in connection with projects. To recover the project, he says, it must be assessed without prejudgment or bias
  • From Small Projects, Large Projects Grow. Chris Vandersluis notes the fascination people have with large projects – the larger the better. He wonders if down-sizing from a giant project to a number of smaller ones doesn’t make sense
  • Where will BA/PM Professionals Come from? Next Steps. This is the final article in Bob Wysock’s seven part series in which he suggested that it might make sense to blend the BA and PM roles into one. See if you and Bob agree in this final piece
  • Where Risk Management Trumps Quality Principles. In this month’s blog, Mike Lecky takes the recent tainted meat tragedy and questions some of the testing practices in the industry. He asks project managers to see if there is a lesson to be learned in developing a project quality plan
  • Is Project Management an Everyday Job? Andrew Miller questions why so much importance is put on the PM always being onsite. He says it can lead to interference rather than leadership and can often just be in the way. He points out that with today’s technology, the PM need never be far away

We hope you find this latest issue of Project Times useful and informative. Please give us your thoughts about this one and what you would like to see in future issues.

Recovering Distressed Projects (part 1 of 2)

Written by Cynthia Low on . Posted in Articles. 3 Comments on Recovering Distressed Projects (part 1 of 2)

Over the past few years, assignments involving “distressed projects” have been frequent…far too frequent for the maturing state of corporate project management. Requests to “recover” a project that has strayed into the territory called “distressed” usually come complete with a “hair’s on fire” urgency to locate and solve issues including emotional distress, protectionism, and a myriad of other valid reasons for the current condition. Amidst the chaos and high-emotion, the project must be assessed without prejudgment or bias, and lead to a path of recovery. This two-part series will deal with a consulting life-cycle approach to uncovering issues that have contributed to the distressed condition and recovering as many of the project’s original objectives and expectations as possible. Distressed projects have no industry preference; they are equal opportunity employers. Therefore, the practices discussed here are applicable to all industry types.

Defining Distress
In our consulting practice, we generally use the term “distressed” to represent a project or program that is 20%> off its cost and schedule baseline targets, exhibits missed milestones and has missed key deliverables. For the sake of recovering a project to its original scope expectations, the earlier the project is recognized as “sliding” the better. You may be asking, “Why only recover the scope expectations?” In many recovery efforts, our involvement begins well beyond the beginning phase of the “slide”. It is a foregone conclusion that the schedule and budget will need to be expanded to allow for original scope expectations to be met. In cases where schedule and budget cannot be expanded, scope is decreased to meet these constraints. PM stands for project management…not project magic! When a project has slipped into serious distress, recovering scope expectations in a stressful environment without major time and cost overruns is a feat in and of itself.

The Basic Life-Cycle
Although all distressed projects have unique issues, we have had success in using a basic and consistent life-cycle approach. The four-phase life cycle pictured below (truncated) has been developed over time and over many of these types of assignments. It is free of non-value added deliverables and is aimed at quickly and accurately getting to the heart of the distress, implementing the corrective action plan, executing and controlling new deliverable development, and executing formal project closure practices/processes.

Entering Phase
Someone once asked me why we call it “entering” and not “initiation”. My response was that the project already had an initiation phase. We are not initiating a project; we are entering a project that is in progress and has specific history associated with it. The term “entering” reminds us that we are not starting with a clean slate. To the contrary, we are in the middle of something failing that requires professionalism, patience, insight, tact and critical thinking in order to make a positive impact. Also, we are reminded that entering in the middle means we must exercise diligence to quickly get caught up on the underlying context of the project. This requires much listening and observation.

Scope Development
Whether we are consultants or internal resources, developing the consulting scope to recover a distressed project generally involves achieving clarity around and documenting the following areas:

  • Initial project expectations (history)
  • Current organizational assessment of the project
  • Expectations of the recovery assignment
  • Scope of Authority: The party or individual who has brought us into the project and our scope of authority going forward
  • Internal Contacts and Key Resources
  • Agreement on our approach (or variations) to the assignment

Schedule Initial Interviews and Data Gathering
In order to properly assess the project, we must interview a varied group of individuals who are directly and indirectly involved with the project. Generally (and hopefully), the individual responsible for our involvement with the project will have identified the organization’s key resources. At a minimum, the following resources should be interviewed:

  • Project Sponsor and/or Steering Committee Members
  • Project Customer
  • Project Manager and Staff (collectively and individually)
  • Key Functional Managers
  • Key Technical SME’s and/or Team Leads
  • Schedulers, Controls Resources, and PMO Resources (if applicable)
  • Key Project Team Resources (formal and informal leaders)

As mentioned earlier, each will have a story to tell about the original intent and why they feel the project has declined to its current status. One must be careful not to get hooked into the emotion of the situation. I recently entered into a very large program that was in a critical state. The emotions were highly charged…fingers being pointed in all directions and mistrust was on the rise as various functional groups took up their positions of defense. Experience teaches one to get past the emotion by calling them back to the real events…what happened (not why) versus their opinion of what happened, i.e., the “news” not the “weather report”.

Also, when one gets caught up in the emotions of the project, it is easy, with no malice aforethought, to agree with folks about just how distressed the project is. As innocent as this may be, it should be avoided at all costs. One of the first cautions of “entering” into a distressed project that will assist us in being quickly accepted as a non-biased pair of “cold-eyes” is being very careful not to “call the baby ugly”. Regardless of the current condition of the project, many people have worked very hard and generally have done what they thought to be the right thing. They have been surrounded by the project daily, which, after a while tends to limit one’s observations and insights. We come in fresh and our lack of specific history and emotion allows us to see things they may not. A good rule to use is not to make any observations or pronouncements (public or private) until you have thoroughly assessed the current situation. Project resources appreciate this type of professional restraint and are much easier to work with if they are not on the defensive.

Analysis and Assessment Phase
Depending on the point of entry, i.e., the level of current distress, this phase can be the most labor intensive of the assignment and not a glamorous one either. This is where the picture of the project, past and present, comes together for us. One must have a great deal of tact, yet possess the tenacity of “Lieutenant Columbo” in order to get to the nexus of the distress without alienating everyone at the same time. We will need to maintain very professional relationships during this phase as we will need buy-in and validation for our proposed solution later on.

Conduct Initial Interviews – Data Gathering, Documentation and Data Review/Evaluation, and Probative Interviews
Although distinct, the three processes above share enough commonality for us to discuss them together in this format. Many of the initial interviews will give us access to the project’s required documentation/data. In some instances, the data may be presented to us prior to the interviews. I prefer the latter. Having an opportunity to examine project documentation/data helps me form pointed questions for the interviews. This helps keep the participants focused on what happened, out of the emotional realm. From the consultant’s point of view it helps to keep the interviews from becoming a blur of repetitive conversations.

Once the first round of interviews and documentation/data review has been executed, we will conduct probative interviews that will be used to “drill” into specific areas uncovered earlier. Projects create a great deal of documentation and we can get overwhelmed if we allow the client to make a doc/data dump. To begin with, we will review the following specific documentation:

  • Charter and Project Approval Documentation
  • Project Charter (Initiation Mechanism)
  • Scope Statements (preliminary and definitive), Scope Development Documents, Reviews, and when Scope was “frozen”
  • Baseline Development Documentation
    • Project Estimates including basis of estimate documentation (ROM, Conceptual and Definitive; consistent with project size and complexity)
    • Project Schedules (with resource loading)
    • Project Design Basis Documentation, Reviews, and when Design Basis was “frozen”
  • Project Execution Plan Elements including (at a minimum)
    • Communication Management Strategy
    • Scope – Change Management Strategy
    • Risk Management Strategy
    • Procurement-Vendor Management Strategy
    • Project Controls Management Strategy
  • Integration – Handover – Closeout Management Strategy

Many times, these documents-artifacts have not been created. Or, they were created in order to gain project approval and have not been kept up to date; both are signs that project execution planning may not have been robust enough. Benchmark studies confirm that a lack of execution planning is a key cause in project distress and failure. We will discuss execution planning in detail in Part II.

Developing Conclusions and Solution Approach
This area is where experience plays a predominant role. As previously mentioned, projects are unique in their specific characteristics, yet sources of distress usually align with benchmark findings and common empirical results from one distressed project to the next. This certainly isn’t a rule yet; we do see many of the same “snags” from project to project. Below are just a few of the common distress factors we have seen in the past few years:

  • Ineffective and untimely senior management decisions
  • Ineffective expectations transfer from client to provider (contract terms misunderstood)
  • Ineffective Stakeholder Communication
  • Lack of Execution Planning
  • Lack of Scope and Design Basis Freeze prior to final estimation or definitive contract terms
  • Project or Program is beyond the experience level of the Project/Program Manager
  • Inadequate project structure and/or resources

Solutions are comprised of specific responses to causal factors and vary project to project based on culture, organization, resource levels, management buy-in, etc.

Gaining Approval and Consensus (findings and solutions)
Difficulty or ease in gaining approval, validation, and consensus is usually and directly related to the level at which the causal factors occur. Strategic or senior management level – difficult, Operation or Management level – easier, and Tactical or team resource level – much easier. Regardless of the level, the solution(s) must be presented in a logical, “threaded”, and no-blame manner in order to gain approval and consensus across the necessary constituencies.

In the next and final installment, we will discuss execution planning, control and project closure in detail.

 

Tom Flynn, P.E., PMP is a founding partner and Vice President of Consulting Services at Advanced Management Services, Inc., Tom has initiated and spearheaded the development of the Project and Program Management Division which helped transform AMS into its current position as a leader in the Project Management Consulting and Training industry.

In addition to his technical project management competencies, he also utilizes his extensive training and experience in conflict management-resolution, change management and human development to successfully coach and mentor senior executives, project managers and project team personnel.

 

From Small Projects, Large Projects Grow

Written by Cynthia Low on . Posted in Articles. 2 Comments on From Small Projects, Large Projects Grow

There’s something compelling about the big project, the huge project, the significant project. There must be because almost everywhere I go, people take little projects and try to make them bigger.

It might start innocently enough. The project team brainstorms in the early planning stages and a mind-mapping exercise takes the little project and gives it branches from the main idea and the branches grow twigs and the twigs grow leaves and, before you know it, it’s blocking out the sun!

Or, perhaps a consultant might have thrown in his two cents. “We should do something magnificent,” he might say (thinking of how many of his colleagues might be able to join him on the job.) “It’ll be a project that endures through the ages.”

Whatever the cause, before you know it, the initial idea has now become a humongous idea and the size of the project carries its own risks. The more complex a project is, the more likely it is to fail. We talk a lot in here about being effective, about using our systems to make us as productive as possible, about using resources expeditiously. I’m pontificating all the time about how we can handle those big projects and tackle even bigger ones at the same time, if only we could use our project systems more effectively. If we think of the three sides of the project management triangle: Scope, Time and Resources, we’re always talking about fixing the Time or Resource sides. The one we almost never talk about reducing is “Scope”.

So today: a few thoughts from the chain gang on turning big rocks into little rocks. Yes, that’s right, making a smaller project out of a larger project.

Let’s pause a moment. Doesn’t that go against the grain? Aren’t you having one of those uncomfortable nail-on-chalkboard kind of moments right this second? It’s a cultural thing. As project managers, we embrace complexity. We take it as a challenge. After all, if the project is too simple, they won’t need us. No one wants to put on our resume, “Managed numerous really small, really simple, low-risk projects”. No! What we want is “Managed schedule for the space station” or “Managed 20 year project for Cure for Cancer”. We are pulled to the complex project and that may be part of the problem. It seems like heresy to even promote a simpler project, but let’s suspend our disbelief for a moment and see if it makes sense.

First of all, almost every project can be broken into pieces. In almost every project there is a kernel of an idea; a base functionality or a core construction. Even in large complex projects, breaking the project into manageable pieces makes sense. No one wants a schedule with 100,000 tasks. But 20 projects with 5,000 each might just be manageable.

Even when you’re committed to a set list of functionality, releasing it in phases still makes sense. Yes, I know, there are times when that’s just not possible. While it may be true, it’s the exception, rather than the rule.

“But wait,” you say, “if we do the whole project together, we’ll maintain the overall vision of the project.”

Yes, that’s also true but that benefit comes with a host of risks. Let’s take a look at some of the advantages and disadvantages of making projects smaller:

Advantages

  • On the good side, a smaller project almost always has less risk. It’s smaller, easier to understand. The finish line is that much closer than it would be in a larger project, and the whole team can drive towards the finish almost from the beginning.
  • A smaller project is also easier to schedule resources for. The key personnel in any organization are going to be easier to lock up for a short period for a smaller project than they are for a longer, more complex project. Key resources (we’ve talked about them in the past) can’t be locked up in a single project for long. They’re key for a reason! So, the longer and more complex the project is, the more likely that you’ll only get partial attention from those kinds of folks. The shorter the project is, the more likely the chance that you can get key people dedicated to it.
  • A smaller project gives back some return on investment sooner. It’s true that the return will be lower than what you were hoping for from the entire vision of the bigger project, but it’s return coming in now rather than later and, regardless of how you’re measuring that return, it’s always good to have some value coming back into the organization.
  • Finally, a smaller project makes for faster successes. And shorter, faster successes breed their own energy. The longer and more complex a project is, the more likely it is to suck the energy right out of a team.

Disadvantages

  • Ok, it’s not all grins and giggles. There are a few down sides to making your project smaller. First of all, there’s a significant risk that the initial vision for the project will never be realized. Often what happens is the 80/20 rule takes hold with a vengeance. The first 80% of the value gets delivered with 20% of the effort. The last 20% of the value takes another 80% of effort. So the problem becomes keeping the attention of management or the client when you’ve gotten the first 20% done. By the same token, going for funding piecemeal makes a significant risk that you’ll get funding for the early parts of the project but not the later parts.
  • Next, there’s a chance that we lose cohesion from the original vision. With the project now broken up into smaller pieces, it’s possible that the original idea will be lost as we deal with each tree rather than the forest.
  • If we think of taking an initial vision and breaking it into distinct smaller projects, one of the risks is that it ultimately costs more. While I think this is possible, you’ve got to temper the chance of this happening with the benefit of getting return on investment along the way with the completion of each smaller project that’s part of the whole.

So how do I do it?
Ok, so there are some drawbacks and some advantages to making smaller projects out of your larger projects. If you’ve decided you like the idea how do you do it?

Start with identifying the kernel of the idea within the larger project. If you can identify some kernel of functionality or core principles, see if those can be crafted into a base project from which other parts of the project could evolve.

If you’re looking at technology, then phasing in functionality over time can be another way to articulate the various pieces of a larger vision.

We look at projects to see whether we can divide up their functionality by geography, functionality, people or source of funding. If you stop and look at the whole, there’s almost always a way to break it into pieces. Then you’ve got to decide if you absolutely need to maintain the original vision, which you can do in a separate piece on its own. Call it the integration or supra-project, if you like. We talk about this concept in project management all the time when we train new project managers. “Break the project into smaller and smaller components until you’ve got something you can manage,” we tell people. Keep this in mind as you face the temptation of larger and larger projects.

Chris Vandersluis is the founder and president of HMS Software based in Montreal, Canada. He has an economics degree from Montreal’s McGill University and over 22 years experience in the automation of project control systems. He is a long-standing member of both the Project Management Institute (PMI) and the American Association of Cost Engineers (AACE) and is the founder of the Montreal Chapter of the Microsoft Project Association. Mr. Vandersluis has been published in numerous publications including Fortune Magazine, Heavy Construction News, the Ivey Business Journal, PMI’s PMNetwork and Computing Canada. Mr. Vandersluis has been part of the Microsoft Enterprise Project Management Partner Advisory Council since 2003. He teaches Advanced Project Management at McGill University’s Executive Institute. He can be reached at [email protected]

Where will BA/PM Professionals Come from? Next Steps

Written by Cynthia Low on . Posted in Articles. 6 Comments on Where will BA/PM Professionals Come from? Next Steps

This is the seventh and final article in this series. The first six articles were:
#1 Is It Time for the BA and the PM to Get Hitched?
#2 Effective Requirements Gathering and Management Needs the Skills of both the BA and PM
#3 An Examination of the BA and PM Skills Profiles
#4 A First Pass at Defining the BA/PM Position Family
#5 A First Look under the Hood of the BA/PM Position Family
#6 A Second Look under the Hood of the BA/PM Position Family
#7 Where will BA/PM Professionals Come from? Next Steps

These articles described the BA/PM professional, why we need such a professional, how the BA/PM position family and career path might be defined and what a professional development program might look like. This closing article focuses on the next steps that might be taken to bring the BA/PM professional into reality. In total then the seven articles lay out by example a blueprint for moving forward. Early in the 1990s, I had the opportunity to design, build and deploy a similar application for IT professionals. Many of the components of that application are analogs of the system I am proposing below. The technology is much more sophisticated now, but I have been there and done that. The following is my suggestion for the system that can provide for the career planning and professional development of BA/PM professionals. It is the logical consequence of the six previous articles.

A System to Prepare BA/PM Professionals
The project to design and develop this system will be a challenging project, but you already should have guessed that. Like every effective project manager, let’s begin this project with what I call a Project Overview Statement (POS). For the PMs this is similar to your PMBOK Project Charter. For the BAs this is similar to your BABOK Project Scope Statement. This POS will be the framework and guide for all project work to follow. For reference purposes, this project will be called the PDP Systems Design and Development Project. This article does not discuss deployment. Deployment of the PDP System is left for another project and is briefly mentioned below.

Project Overview
StatementThe POS is the first document that describes a proposed project. It is a high-level description of a business situation and what you propose to do about it. It is a one page document with five parts. I have used it for more than 40 years with great success. For the PDP Systems Design and Development Project here is my version of the five parts of the POS.

Problem/ Opportunity
The project landscape is changing. Complexity and uncertainty dominate. Only rarely can requirements be completely defined and documented at the outset. An agile approach to these projects is highly recommended. To be effective in managing these projects the agile project manager must be fully skilled in both project management and business analysis.

Goal
Design and develop an internet-based career planning and professional development system to prepare professionals to be both project managers and business analysts at all levels of skill and competency so that they are fully capable of successfully managing projects at all levels of complexity and uncertainty. This new professional is called a BA/PM professional.

Objectives

  • Define the BA/PM position family 
  • Define the BA/PM career paths 
  • Identify the skills and competencies required of the BA/PM professional 
  • Establish the minimum skill/competency proficiency profile of each BA/PM professional 
  • Define the internet-based Professional Development Program (PDP) 
  • Design the skill and competency assessment tools portfolio 
  • Design the career planning module 
  • Design the professional development module 
  • Design the integrated PDP System 
  • Develop the integrated PDP System 
  • Document the integrated PDP System

Success Criteria 

  • The PDP System will be a thin client internet-based system
  • The PDP System will be ready for deployment within 12 months of starting the project 
  • The PDP System will be parameter-driven and fully support user definable PM and BA position families, career paths and skill/competency profiles 
  • Using the PDP System will not require any training – it will be intuitive. 
  • The PDP System will not have a User Guide.

Assumptions, Risks, Obstacles 

  • The need for a BA/PM professional will not be acceptable to the entire BA and PM communities 
  • The project will be co-managed by a representative from the PM community and a representative from the BA community 
  • Qualified technical resources will be made available when needed to design and build the PDP System 
  • The BA and PM communities will be honest participants in reviewing and commenting on the PDP System 
  • An agile project management approach will successfully deliver the PDP System 
  • A sponsor can be found to financially support the project

Suggested High-level Work Breakdown Structure
Once the POS has been approved by representatives from both the BA and PM communities detailed project planning can begin. A high-level work breakdown structure might look something like the following:

Phase I Scoping the PDP System

  1. Describe the PDP System Task Force purpose and membership 
  2. Recruit the PDP System Task Force members 
  3. Plan and hold the PDP System Kick-off Meeting 
  4. Synthesize current BABOK and PMBOK position definition & documentation 
  5. Document the requirements of the desired PDP System

Phase I: PDP System High-level Design 

  1. Define and document the PDP System deliverables 
  2. Define and document the PDP System process flow 
  3. Gain approval of the PDP System high-level design

Phase III PDP System Detailed Design & Documentation

  1. Recruit the PDP System Development Team 
  2. Design the documentation format and templates 
  3. Construct the PDP System documentation 
  4. Circulate PDP System documentation for review 
  5. Revise PDP System documentation 
  6. Gain approval of the PDP System detailed design

Phase IV PDP System Development 

  1. Recruit PDP System Development co-project managers 
  2. Recruit PDP System Development Team 
  3. Review the PDP System documentation 
  4. Define the PDP System Technical Requirements and Architecture 
  5. Prioritize PDP System Requirements 
  6. Define PDP System Development cycles (plan, build, check) and time boxes 
  7. Execute PDP System Development Cycles 
  8. Demonstrate having met the requirements of the PDP System Task Force 
  9. Discharge the PDP System Development Team

Phase V PDP System Marketing

  1. Create the PDP System Marketing Program 
  2. Plan and publish PDP System articles 
  3. Design and produce PDP System promotional materials 
  4. Distribute PDP System promotional materials 
  5. Discharge PDP System Task Force

A Call to Action
So there you have it! The complexity and challenge of the PDP System Design and Development Project should not be underestimated. Its importance cannot be overstated either. It is my firm belief that having BA/PM professionals on your staff will have a significant impact on project success.
Testimonial data that I have gathered over the years from over 10,000 project managers worldwide suggests that over 70% of all projects are in the agile category. These projects are such that requirements identification and solution definition can only come about from learning and discovery during project execution. That requires that some form of iterative approach be employed. This is clearly the domain of the agile project and requires the leadership of the BA/PM professional. That they are needed is not debatable. The processes to develop them are by no means obvious or in place.

Through this and the preceding articles I’ve tried to build the case for formally recognizing the need for the BA/PM professional and for the systems to meet their career planning and professional development needs. I’ve taken a pass at the high-level work breakdown structure as the beginnings of the project plan to put the requisite PDP System in place to support those needs.
How might we make that plan happen? If your organization sees the importance and the need for such a system and suffers the pains of frequently occurring distressed projects and excessive project failure, perhaps they would be interested in funding a PDP Systems Design, Development and Deployment Project to meet their own needs. This would get us off to a fast track start. Could your employer be one of those companies?

Alternatively, a BA or PM product/service provider might be interested in adding the PDP System to their portfolio through a joint venture to design, develop, market and sell the PDP System. Do you work for such a company?

In any case the next step for me is to recruit a BA professional who would be interested in partnering with me to take a BA/PM advocacy position and then to begin working on the PDP System. If you and I are of like mind, if you are an accomplished BA professional, if you have name recognition in the BA community, if you have some time and would like to make a difference, I would like to hear from you. My direct email is [email protected]. I’m serious!

Robert K. Wysocki, Ph.D., has over 40 years experience as a project management consultant and trainer, information systems manager, systems and management consultant, author, training developer and provider. He has written fourteen books on project management and information systems management. One of his books, Effective Project Management: Traditional, Adaptive, Extreme,3rd Edition, has been a best seller and is recommended by the Project Management Institute for the library of every project manager. He has over 30 publications in professional and trade journals and has made more than 100 presentations at professional and trade conferences and meetings. He has developed more than 20 project management courses and trained over 10,000 project managers.