Skip to main content

Perhaps It

Editor’s Comments

With this Project Times, we’re running the first in a series of articles from Business Analyst Times by Bob Wysocki that asks the question, Is it Time for the BA and the PM to Get Hitched? He weighs in with the view that there is a lot of overlap between requirements gathering and management and wonders if the BA and the PM roles shouldn’t be rolled into one. It caused much controversy amongst the Business Analyst Times readers, and we’d love to hear what you think from a project manager’s standpoint. We have added a dedicated BA/PM discussion forum topic here.

Is the title “project manager” becoming trendy? Maybe it always was and we just didn’t notice! Chris Vandersluis doesn’t think so, but he’s concerned that the position of project manager is becoming trivialized on TV soaps and “reality” shows. In his article, Head for the Hills, he takes the PM industry to task for creating the expectation that anyone can become a project manager. He digs deeper to find out why.

On the other hand, Catherine Daw believes that project management isn’t always taken as seriously as it should at senior management levels. In Telling Truth to Power, Catherine addresses the importance of top management support for projects. But, she says, along with that is the need to be able to pass along bad news with the good, something that’s often difficult, especially if management is throwing stumbling blocks in the project’s way, and doesn’t really want to know.

Jim Lecky and Andrew Miller are back with their monthly blogs and they too would like to hear from you.

Is it Time for the BA and the PM to Get Hitched?

This article first appeared in the May 1, 2008 Business Analyst Times

My life as a project manager (PM) began in 1963 at Texas Instruments at about the time IBM announced System 360. It was a landmark event in the history of computing and little did I know at the time but it was also the wakeup call that a revolution was about to take place. It was a revolution that we weren’t ready for. If I remember correctly I ran projects but was called a systems consultant. I don’t recall anyone in my industry carrying the title project manager.

There was very little in the way of tools, templates and processes to support me. The only software that I knew about was an old IBM1130 program that I think was called Process Control System. One of my friends in the building construction trade introduced me to it and I thought I was now king of the hill. PMI wouldn’t arrive on the scene until 1969.

As for the business analyst (BA) they weren’t around, at least not by that name. What we did have were computer professionals that were called systems analysts. They were the mystics from the IT Department who could talk to a businessperson about what they wanted, retreat into their space to concoct a solution, emerge to tell the programmers what to build and then hope for the best. Few clients were satisfied with the results but they weren’t involved enough to know what to do about it. Life was tough in those early days of project management and systems development. Clients were kept at arm’s length and only got involved when it was time to sign a document under the threat of a project delay if they didn’t sign. Every one of my colleagues, including myself, was looking for silver bullets.

Fast forward to 2008. The systems development landscape is more mature as are the life cycles employed. We have linear, incremental, iterative, adaptive and extreme projects. In less than 40 years PMI has grown to over 250,000 members worldwide. It is the de facto professional society for PMs. IIBA, launched in 2003, is just getting started and has a membership of over 4,000 worldwide. Size differences aside the two organizations have a lot in common and a lot to gain through collaboration and joint ventures.

The major area of overlap is requirements gathering and management. Both the PM and the BA face the same challenges here. Even under the best of circumstances it is very difficult, if not impossible, to identify and document complete requirements. The reasons are many and well known to both professional groups. Underlying it all is the need for more collaborative efforts.

The next area of overlap is process improvement. In the world of the PM and their management this means applying some variation of the Capability Maturity Model and continuous project management process and practice improvement. For the BA this means business process improvement projects and that means having effective project management methodologies.

The next area of overlap is the skill and competency profile of the effective PM and the effective BA. The two profiles are virtually identical. Some have posited that we really don’t need both types assigned to the same project. We could certainly debate that point of view but, if present trends continue, I would argue that a single person, whatever label you choose to use, will soon be sufficient. In other words the BA should have the requisite skills and competencies to be an effective PM and the PM should have the requisite skills and competencies to be an effective BA. They will have morphed into one professional. Lacking an appropriate name right now, I’ll refer to this single professional as a BA/PM. We are not too far away from that day.

The next area of overlap is the processes, tools and templates that both professionals follow. Again they are virtually identical at the concept level.

I could go on but I think you get the picture. I am led to the conclusion that the support of both the PM and the BA should lie in a single organizational entity that I am going to call the Business Project, Program, Portfolio and Process Office or BP4O for short. Please excuse my taking liberties with the multiple use of “P”. I do that for good reason. PMs have had the Project Management Office (PMO) under various names for a number of years. The BA has not had a similar support organization. Recently I have seen Communities of Practice (COP) and Centers of Excellence (COE) emerging for the BA, but these are more voluntary forums for the BA to network and exchange ideas with their peers than an organized business unit. There is no valid argument that can be given for not expanding the PMO to embrace the BA. That is what I am calling the BP4O and that is the focus of the remainder of this article.

The World Class BP4O
On the surface the world class BP4O won’t seem much different than the traditional PMO. The world class BP4O offers an expanded portfolio of support functions as compared to the typical PMO but if you look under the hood, you will see that I am proposing that there be a significant difference. In organizations that see the handwriting they see that project management, program management, portfolio management and business process management are all converging on a single strategic role with enterprise-wide scope. The world class BP4O that I envision is a central participant in that role. It helps define strategy and through its infrastructure provides for the enablement of that strategy too. And so here is my first shot at a definition of the world class BP4O.

Definition of the World Class BP4O
The world class BP4O is an enterprise-wide organizational unit that helps formulate and fully supports the strategic, tactical and operational initiatives of the enterprise. The world class BP4O is characterized by:

  • Led by the VP BP4O who has a voting seat at the strategy table
  • Fully participates in the formation and approval of the business plan at all levels
  • Establishes the processes for and monitors the performance of the project portfolio
  • Has authority and responsibility to set priorities and allocate resources to projects
  • Establishes standards for the tools, templates and processes used by BAs and PMs
  • Monitors compliance in the tools, templates and processes used by BAs and PMs
  • Establishes an integrated BA/PM position family with defined career paths
  • Provides a complete program (training and human resource management) for the professional development of all BA/PMs
  • Assures that the skill and competency profile of the BA/PM staff is sufficient for the realization of the project portfolio
  • Allocates BA/PMs to the approved portfolio of projects
  • Offers a full range of support services to executives, sponsors and project teams
  • All BA/PMs have an approved professional development program.
  • Performance metrics:
    • The project management and business process methodologies are assessed at CMMI Maturity Level 5
    • On average the practice maturity level is at least CMMI Maturity Level 3
    • The project failure rate is less than 10%

As you can see the VP BP4O is an integral part of the enterprise from the strategy formation level to tactical planning to execution at the operational level. It is that unit’s responsibility to make the most effective use of the enterprise’s human resources towards the realization of the business plan.

Mission of the World Class BP4O
To provide a comprehensive portfolio of strategic, tactical and operational support services to all project teams, sponsors and executives in order to assure the delivery of maximum business value from the project portfolio.

Objectives of the World Class BP4O

  • Define a project life cycle with stage gate approvals.
  • Design, develop, deploy and support a comprehensive portfolio of tools, templates and processes to effectively support all projects.
  • Design and deploy a project review process to support project teams and monitor compliance to established standards and practices.
  • Establish a project portfolio management process to maximize the business value of project investments.
  • Establish a decision support system and dashboard to support executive management’s project decisions and provide for the timely monitoring of the project portfolio status.
  • Design, develop, deploy and support a comprehensive HR Project Management System.
  • Design, develop, deploy and support a continuous process improvement program for the BP4O.

Organizational Structure of the World Class BP4O
The only structure that makes sense to me is one where the BA/PMs are close to their client groups. That structure is what I call the “Hub & Spoke. At the Hub we have the enterprise level unit that is responsible for policy, process and staff development. At the Spokes are the various divisions and departments with their own staff of BA/PMs. They might establish tools, templates and processes specific to their needs but in compliance with the enterprise policies and processes.

Staffing of the World Class BP4O
There are five staffing models that come to mind:

  • Virtual BP4O
    The Virtual BP4O does not have any BA/PMs assigned to it. Instead they are deployed throughout the enterprise where they are assigned on an as needed basis by their organizational unit. These are not fulltime project managers but are professionals in other disciplines who have project management skills and competencies as part of their toolkit.
    The BP4O staff consists of a manager and one or more assistants who support BA/PMs as required. They may be BA/PMs but that is not necessary. The important thing is that this staff has the necessary expertise to provide the support needed. The support services may span the full list but are often quite restricted because of staff limitations.
  • BA/PMs are assigned to the BP4O on a rotating basis
    This is an excellent model for deploying the BA/PM methodology, skills and competencies throughout the organization. In this model BA/PMs from the business units are temporarily assigned to the BP4O as a sabbatical from being on the firing line too long. A sabbatical might last from 3-6 months during which time they might conduct a specific process improvement project or simply act as mentor and coach to other BA/PMs.
  • BA/PMs assigned to the BP4O
    In this structure the BP4O BA/PMs manage critical mission or enterprise-wide projects. Usually not all BA/PMs report to the BP4O. There will be several who are assigned to business units to work on less comprehensive projects for their unit.
  • BA/PMs assigned at the division level
    BA/PMs assigned at the division level work on division-wide projects. These may be projects that span two or more departments.
  • BA/PMs assigned at the department level
    Same as the division level except they are assigned within a department and only work on projects contained within their department.

Summary
This article is an opening gambit for me. My hope is to expand on some of the ideas expressed above in future articles. I hope that this article has provided food for thought and that you will take the time to let us have your comments.


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.

The Rules of Lean Project Management: Part 2

This is my second blog entry on the main rules of Lean Project Management, as I see them. It is somewhat linked to the first one, the “Last Planner” rule which says: “The one who executes the work is the one who plans the work.”

What type of work should the Last Planner plan to execute ensure the success of his/her part of the project? The Lean Construction Institute[1] proposes a very simple answer to this question. Projects can be successfully managed by planning and executing reliable promises. What are reliable promises? They are small deliverables that one agrees to complete in a very small timeframe, usually on a weekly basis. This is done for the ongoing project phase/stage and, if we really know what we are doing (according to rolling wave planning principles[2]), it is usually possible to cut the project into more manageable tiny bits. This approach, known as the Percent Plan/Promises Complete (PPC) is a mix of:

  • The agile software development “timeboxing”[3] approach, applied on an individual basis and
  • Earned value management using deliverables realised as a measure of project performance achievement, the ultimate seeing is believing measure.

Cutting projects into very small promises that we can literally see at the end of each week is effective in at least three ways:

  • First, you are in a position to see rapidly tangible progress on the project
  • Second, you can also quickly see when the project is getting off track and correct the course while time and cost variances are still small enough to be correctable.
  • Third, according to research by Goldratt, among others, productivity is greatly improved since reduces the time for the Last Planner where to pick up the work still to do after being interrupted. The work then has to be rescheduled to meet timelines. According to some time management studies, people spend in average close to 50% of their workweek on not-planned-for urgent work that comes in the form of frequent interruptions, frequent meaning on average every 30 minutes. Sound familiar?

Using weekly PPC as a measure of progress also has the advantage of giving early feedback about how and where to improve project delivery performance. Some empirical data[4] show instances where project teams managed to increase their PPC from 50 % at the start of a project to more than 80% within a 10 to 12 week timeframe, which is the equivalent of a 60% increase in speed of delivery.

Tracking small deliverables is very simple to do and does not require a complex reporting system (computing timesheets, project expenses, etc.) to accomplish. In all the things I propose, this is also the one approach that the vast majority of participants in my workshops like the most and want to put into place in their organization as soon as possible. And frankly, I believe that if you stick to delivering those small promises, and succeed most of the time, you will discover when you receive your “hours spent and/or incurred costs” report (usually containing one-month old obsolete data), that you are on budget. You already know that you are on time, because you see the promises coming out every week.

So LPM rule No. 2 is: “Do not track time (effort) or cost; track small promises that you can see over time”

And if you want to put together your PPC system fast, there is help available. Just read Hal Macomber’s excellent article “Securing Reliable Promises on Projects”[5] and you will be up and running fast-delivery projects successfully in no time at all.

1 http://www.leanconstruction.org/
2 http://www.maxwideman.com/issacons/iac1077/tsld002.htm
3 http://en.wikipedia.org/wiki/Time_boxing
4 https://www.projecttimes.com/wp-content/uploads/attachments/LCICurt.pdf
5 https://www.projecttimes.com/wp-content/uploads/attachments/reliable_promises.pdf

Newer Isn

As financial services companies diversify their product and service offerings, the technology systems that support these endeavors often remain as independent silos, with little or no cohesive integration. While some companies focus on ripping out older systems, this can result in exorbitant costs. Others are seeking more pragmatic approaches, like service oriented architecture (SOA).

Such was the case for Landesbank Baden-W

LBBW was challenged with what to do with its existing legacy mainframe applications (a.k.a.

Putting the Project Manager in the Driver

A project manager’s training, skills and techniques serve to accomplish one major objective; to provide the project manager a vehicle to successfully attain a goal or target. As with any vehicle the operator must have some training to maneuver and control its progress. The vehicle itself provides no guarantee of reaching the destination or of successful goal attainment. Vehicle quality may also have a bearing on the overall performance and experience. It is the driver that must determine the direction, the route and the rate of speed given the vehicle’s characteristics. Such is the case with project management.

A project manager’s training is relatively well defined. The training or vehicle, so to speak, comes in many shapes and sizes with different levels of performance. Suffice to say that vehicle specifications are generally standard in that there are basic requirements to creating a mode of transportation. Not unlike a project manager’s training. There are basic requirements in a PM’s training that are relatively standard. Take the PMBOK for instance representing the specifications to assemble a knowledge-based vehicle for the project manager to utilize. Once mastered it requires that innate or learned ability to take that vehicle and embark on a journey towards a goal. In most cases, as the project manager/driver, you will have passengers who rely on your judgment and will experience your abilities as a driver and leader. On occasion your passengers or team members will have some input that you may wish to consider in your journey.

This brings us to the next level of a project manager’s development, which deals with maturity and ability. Not all trained drivers can master a vehicle with ease, so too is the case with project managers. A fortunate few are born with an innate ability and reach their comfort zone relatively easily and quickly. The vast majorities are left with a time of trial and error and sweating the details until it becomes second nature. Many of us struggle to get the feel of it and find ourselves constantly challenged in an effort to achieve balance from project to project.

Armed with training, experience and a few times at the wheel you tend to organize your mental stimuli on each project to determine what needs your attention most, when is it needed, and to what level of involvement it is needed. It helps also to determine what requires little of your attention. Consider your progress as a driver: As you became more adept and mature, you tended to focus on the aspects of driving that got you safely and expeditiously to your destination. During your initial days at the wheel, you read each and every sign posted and followed every marking so as not to miss any details. In some cases this attention to detail affected your progress, or may have even got you lost, which left you exhausted and consumed when you finally arrived at your destination. Similarly, with project management we must achieve a level of maturity from the knowledge and experience that helps us zero in and ”feel” the project, not just read all the dashboards and reports to reach conclusions.

There are some basic steps to acquiring a comfortable level of maturity. It takes a well-trained eye and a bit of experience to develop to this stage. Following an in-depth and clear understanding of the undertaking, the PM will recognize three aspects that play a leading role in determining the project’s “feel”. The first aspect is Awareness. The second is Priority and the third aspect is Urgency. (APU).

Awareness involves information gathering. It requires early stage analysis of scope, data, documents, contracts, organizational structures, politics, personnel and whatever details may be available. As the project develops through its stages so does the requirement to become aware of each added feature to the overall scheme. Awareness is primarily a quantitative analysis. It requires some judgment but also requires considerable understanding of the role each piece of knowledge base plays in the big picture. This step gives you the basic raw materials needed to assemble the framework from which you will build your model of management. You will, in all likelihood, have a checklist of standard features you feel are required to complete your model of how the project should be managed. You may introduce features such as scheduling or cost control, or you may find that your model requires expertise and, therefore, additional resources. After completing this stage of knowledge absorption, the next step is setting the priorities.

Priorities involve identifying those features or activities you absorbed in the awareness stage, which will create a “no go” situation in your overall progress if a non-compliance should occur. A non-compliance can be a delay in progress, a missing document, or an unfulfilled step in the process. As a project manager it becomes crucial to identify these potential non-conformances and devote additional attention to them to prevent them from crippling your program. It serves to make efficient use of the PM’s time, thus avoiding excessive effort on non-essential activities. In many cases, a well-defined network schedule or cost plan is very useful in identifying these priorities. However, in several instances the plan may not hold enough information to be useful in all cases. Take for instance a departmental political situation that may be affecting a judgment call crucial to the project. In another instance a minor unresolved engineering detail may delay a larger issue of information, or a financial foul-up could stop activities due to lack of funds. Being fully aware of the critical aspects allows the PM to surgically focus his attention. In addition, it is vital to document and communicate these priorities and focus on them during meetings and dealings with members of the project team. This increases the team’s awareness and places more eyes and ears on the potential problem, which then leads us to the aspect of urgency.

Urgency is the level of effort that will be injected into each feature of your program or project, based on its priority. Urgency must be measured very carefully to avoid the “cry wolf” syndrome. The PM with his awareness stage completed, his priorities determined and with his judgment in tact will then decide how hard to press on the throttle. It is this aspect of his responsibilities that may determine the success or failure of the project. Urgency is generally preceded by a decision to act in some form. Similar to driving a car, reckless or indiscriminate use of urgency fosters fear and distrust thus loosing the support and confidence of those who you need most to achieve success. Applying urgency appropriately and justifiably helps build trust in your judgment and confidence in the actions needed to resolve a crisis. It also helps you attain maturity and respect.

In conclusion a project manager needs formal training in the skills of PM but must also develop a sense of awareness, priority and urgency to apply the skills learned and needed. This sense quite often is the result of trial and error through one’s developmental stages or via a mentoring program. Experienced managers generally recognize the difficulty in transferring this sense, or savvy, to new managers since, having spent years developing this intangible in themselves, they often feel that only time and practice can help develop it in a new PM.


Robert Mattia is a project manager and operations manager with The State Group International L.L.C, which is embarking on a joint venture business development with S.S. Lootah International in the UAE. He has been with The State Group for the last 14 years and possesses a Bachelor of Technology from Ryerson Polytechnical University (1978) with a major in Project Management. He is a designated A.Sc.T. with the Ontario Association of Certified Engineering Technicians and Technologists, and holds a Certificate in ADR (Alternative Dispute Resolution).