Tag: Career

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.

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]

Why is there such a focus on project managers being on site all day, everyday? Am I the only one that has noticed that? Whenever I talk with clients or colleagues about PM positions whether full-time or on contract, the focus seems to always be on being on site all of the time. In today’s world of global projects and excellent technology, I would submit that being on site could sometimes be a hindrance.
I understand, of course, that on projects where the team is there everyday working on tasks and deliverables, etc., someone needs to be there to answer questions, provide leadership and ensure things are moving as planned. I have been on many projects where this is the case and I have found that sometimes it is detrimental to the team to have the PM around all the time. Teams can use the PM as a crutch where, instead of researching the answer to a question or sharing the information with each other, everything needs to funnel through the PM. This leads to a dangerous level of dependence on the PM and does not evoke a very trusting environment. If I cannot trust my team to work on their tasks and deliverables just because I am not there watching over their shoulders, then maybe I have the wrong team.

If a PM’s job is to provide leadership, manage team members, communicate to leadership, work with suppliers and ensure goals and objectives are bring met, then why does being there every day mean all of this will be done? Are Presidents and CEOs present everyday at their workplace? Absolutely not, yet amazingly work seems to get done. My fear is that the world of project management has become one of controlling, not of providing skills and expertise to successfully implement strategic initiatives. It has become a question of how often can you be here, not what value is the organization going to get as a result of this project.

With today’s technology, I am reachable wherever I may be, whether on the beach, at a conference or in my office. Through phone or email, I can almost always be reached (except on planes, but that is outside of my control) If there are issues on a project, I can be reached, even if I am not on site. My MO is to check in with my project teams on a regular basis through face to face meetings, phone and email, but not to be on site all day everyday for the life of a project. I have found that this works effectively because it builds independence within the team, but also provides a safety net of communication when issues do arise. I encourage my teams to call me whenever they need to and I like to create open dialogue. If we see the results, then there is no relevance whether I am on site or not. You can call me the Virtual Project Manager!

This is the sixth article in the series. In the previous article (A First Look under the Hood of the BA/PM Position Family) I defined the BA/PM position family and the career path sequence. Then I wrote the generic position descriptions of the six-position family. The structure and ordering of the six positions in the BA/PM landscape is now defined at the generic level. Each of the 36 cells in the BA/PM landscape has now been generically defined with respect to the BA/PM position family.

Depending on the extent to which project management and business analysis exists in your organization, there may be empty cells or cells with more than one position title in them. If your organization has more than one specific position title in a cell, then there will probably be some ordering of those position titles with respect to their skill and competency profile. So the career path may contain advancements to positions within a single cell. The minimum skill and competency profile required to enter a cell at the lowest position is work that still remains to be done. That will require a significant effort and help from both the PM and the BA side. That discussion is left for a future article.

A Deeper Look into the BA/PM Landscape

Since we now have a BA/PM generic position family defined and a career path for that family, Figure 1 takes on more meaning. An example will help. Figure 1 shows an individual whose current position is in the BA/pm Associate Manager cell. This person is a professional project manager with basic business analysis skills and competencies. This is a very common position. Recognizing the importance and value of having stronger business, their short-term goal is to have a position in the BA/PM Associate Manager cell. To do this, they will build a plan in their Professional Development Program (PDP) to accomplish their short-term career goal. Their PDP will focus on improving their business analysis skill and competency profile from that of a PM/ba Associate Manager to that of a PM/BA Associate Manager. The PDP for this person might contain the following strategies:

Experience Acquisition

• Seek out project assignments that have more of a business analysis focus than they are accustomed to.
• Support professionals who are more senior to you and have a business analysis skill that you need to improve to better meet current position requirements.

On-the-job Training

• Look for opportunities to observe and support the business analysis work of BA/PM professionals
• Take courses (on or off site) to enhance the business analysis skills required of your current position

Off-the-job Training

• Take courses (on or off site) to add business analysis skills that will be required by your targeted position in the PM/BA Associate Manager cell
• Look for opportunities to observe and support a professional practicing the business analysis skills you will need in your targeted position.

Professional Activities

• Read books and journal articles on topics relevant to your targeted position in the PM/BA Associate Manager cell
• Attend meetings and conferences offering seminars and workshops relevant to your targeted position in the PM/BA Associate Manager cell

Figure 1: Using the BA/PM Landscape for a Short-Term Professional Goal in the same Position

In my experience with PDPs they tend to cover an annual planning horizon with at least semi-annual status meetings with a mentor, or as needed meetings that you will request.

Figure 2 illustrates an example that is a little more complex. Here the short-term PDP is targeting a change from a position in the PM/ba Associate Manager cell to a position in the PM/ba Senior Manager cell. As you can see the Core, PM and ba skills profiles will be affected. The ba skills profile will be minimally affected only by the change of position level.

Figure 3 is a combination of the situations depicted in Figures 1 and 2. It illustrates yet another example of a more complex situation than is illustrated in Figures 1 and 2. Here the change is not only to a higher level position (Associate Manager to Senior Manager) as was the case in Figure 2 but also to a position requiring a broader and deeper business analysis skills profile (ba to BA) as was the case in Figure 1. A career change like this may take some time to accomplish. Not only will the person need to acquire additional experience to qualify for the higher level position, they will also need to increase their business analysis experience, and skill and competency profile, to qualify for the higher level position’s business analysis requirements. A better professional development plan might be to follow one of the two-step strategies below:

PM/ba Associate Manager -> PM/BA Associate Manager -> PM/BA Senior Manager

or

PM/ba Associate Manager -> PM/ba Senior Manager -> PM/BA Senior Manager

The likely promotion opportunities may help you choose the better of the two strategies.

Career Planning Using the BA/PM Landscape

A section of the PDP should be devoted to long range career planning. The BA/PM landscape is a tool that can aid in the planning process. Figure 4 illustrates a career path leading from a position in the BA Team Member cell to a position in the BA/PM Senior Manager cell. The CareerAgent System that I mentioned in an earlier article (A First Pass at Defining the BA/PM Position Family) included a decision support system that helped the individual plan their career path down to the position title level within the cells. It mapped out a training and development sequence leading from position to position across the BA/PM landscape until the final career goal had been reached.

As the plan is executed it will most likely change. Even the targeted position might change. There are several factors that will influence the plan and suggest revisions more compatible with the changing business environment and that offer more career growth and professional development opportunities.

A Call to Action

In the previous article (A First Look Under the Hood of the BA/PM Positin Family) I stated that this is a work in progress. I have participated in the development of similar structures for the IT professional but not for the BA/PM professional (or PM/BA if you prefer). Much remains to be done. I welcome a partner from the BA side to work with me in this challenging and valuable pursuit. It is my hope that I have launched this effort in a direction that ultimately will make sense across the entire BA and PM professional landscape. If you are interested in discussing a possible collaboration, you may reach me directly at [email protected].

Putting It All Together

In this article I have shown by example how the BA/PM landscape and BA/PM position family would be used in professional development and career planning.

The responses to the first five articles have been overwhelming. They have been both positive and negative. Being a change management advocate I am thankful for your interest but not surprised with your reactions. My hope is that we can continue the exchange. As always I welcome opposing positions and the opportunity to engage in public discussions. Your substantive comments are valuable. Criticism is fine and is expected but, in the spirit of agile project management, so are suggestions for improvement. Also in the spirit of agile project management, I am trying to find a solution to the career and professional development of the BA, BA/pm, BA/PM, PM/BA, PM/ba and PM.

I realize that I have taken a controversial position and in so doing have stepped out of my comfort zone and perhaps put myself in harm’s way. I do so intentionally. Through all of the earlier articles I hoped to get your attention and that has happened. In this and subsequent articles I hope to get you to start thinking about the care and feeding of a single BA/PM professional – one who is fully skilled in both disciplines. I have a very strong belief that there is a crying need for the BA/PM professional. As you dig deeper into the BA/PM through this series I ask that you approach my suggestions with an open mind and offer your ideas in this public forum.

---

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 skills of the project manager need to match the project and the people involved.

It’s an important issue since the success of a project is dependent on the competency of the project manager. Every project is different and this presents a challenge.
So how do we minimize the risk of an inappropriate project management assignment?

One approach to treating this risk is to first build an understanding of the project environment, the work involved, the people participating and, last but not least, the customers’ expectations. Then use this understanding to assess the importance of some basic competencies common to most project managers. Your understanding of the environment, work and people will point you to the specific qualities – and to any unique competencies – key to the success of the project.

There are several sources that can be used to frame the ‘basic competencies common to most project managers’. The PMBOK suggests project managers should have domain knowledge in the application area of the project, general management skills, soft skills related to people management, project environment knowledge and understanding and experience in the nine management knowledge areas.

Another view is provided by Jennifer Krahn (from recent PMI Research Conference Proceedings Effective Project Leadership: A Combination of Project Manager Skills and Competencies in Context). From her work, the ten most important skills and competencies for project managers are: people skills, leadership, listening, integrity, trustworthy, verbal communications, team building, conflict resolution, critical thinking and priority balancing.

Yet another alternative is provided by William Lei and Martin Skitmore (from Project Manager Competencies: A Survey of Perspectives from Project Managers in South East Queensland). Lei and Skitmore frame abilities along slightly different lines: meeting project deliverables, making decisions, controlling costs, leading project teams, organization, planning, conflict resolution, problem solving, motivating, meeting project quality objectives, negotiating, delegating tasks, team building and managing legal issues.

To these lists I’d add visioning skills and the ability to manage expectations and conduct effective meetings. Clearly there is no comprehensive, ‘one-size-fits-all’ list for all situations.

When selecting the desired project manager competencies, you identify the characteristics of the project environment, project work and people involved. As an example for a large project high importance might be placed on finding someone with significant relevant prior experience and good team building skills. On the other hand a project with lots of uncertainty may place more importance on critical thinking, risk management and people skills.

We know that projects fail for numerous reasons. Selecting the ‘right’ project manager means selecting the project manager with the ‘right’ competencies. This is one way to reduce the likeliness of failure due to ineffective project management.