Tag: Project Management

Small Projects Drive Me Crazy!

Written by Kupe Kupersmith on January 5, 2010. Posted in Articles.

OK, it is not small projects that drive me crazy. It is what I see project teams doing because a project is classified as a “small” project. Teams get the feeling that there is no need for a BA, no need to follow a process, and/or no need to plan. All of these thoughts just because the project has been labeled as a small project! That’s what drives me bonkers. And what happens on most of these projects? Teams struggle, things are missed, and at the end of this small project, teams scramble to finish up. Of course, no project retrospective is done because; well…it was a small project.

My philosophy is that every project is different, and the team needs to take the steps that add value to the project. This does not mean planning is not important or following a process is not important. It means plan as much as necessary and take the steps in the processes that are needed. You need to analyze each project and determine what makes sense. I know many companies that try to classify projects by size, and then decide if a BA is needed, what techniques to use, how much to document, etc. I have heard people say a small project should have less than 50 pages in a requirements package. So if there are 60 do we no longer classify the project as small? Why try to keep a BA to documenting “x” number of pages? The number of pages should reflect what is needed for that project. The problem with this approach is that projects do not easily fall into buckets. There are too many factors that you need to consider in order to determine what techniques to use, and so on. The type of project, the people on the project, and internal company processes are all high-level factors that need to be considered. Putting projects in buckets opens the team up for failure and focuses the team’s attention on rules in a process. Their attention should be on the customer and the goals of the project.

Teams come up with a process for small projects that are different than large projects because teams try sticking to a prescribed process for every project. Trying to implement every step in a process is overkill for some projects. Coming up with another prescribed process does not solve the problem. In my Going Rogue blog post I think some of you had the impression I do not believe in having a process, or not needing a process as you get more experience. That is not the case. What is true; I don’t believe in a strict prescribed process for everyone and every project. I do believe in a process. It just needs to be fluid and ever-evolving. It has been proven by smarter people than me that having a repeatable process is the key to improvement. A process gives you an anchor to track areas of success and areas for improvement. So, I do believe a process is absolutely necessary.

The only step in a process I can say for sure is needed for every project is planning. For every project the step that must always happen and be taken upfront for a BA is plan the approach for each project. From that plan a determination will be made as to what techniques to use, how much to document, etc. For the techniques chosen, the BA should use the rules or guidelines outlined in the overall process. For example, if use cases are planned to be written for the project, the BA should use the template provided. A BA does not need to complete every step in a process, but if they do perform a step they need to be consistent with the other BAs in the organization.

Projects are not an exact science, so don’t try to place a prescribed process for each and every project. Try to understand the variables of the project, the people, the internal processes, and then plan your approach. I approach projects like I approach my kids. They are each very different, so I treat them in the manner that is best for them. I do not cheer for my oldest daughter at sporting events because she shuts down and stops playing. My son loves when I scream like a raging lunatic at games because he thinks it’s funny. I say it motivates him and he does not want to admit it yet! My youngest daughter, well, I have not figured her out yet!

Happy New Year everyone. I am looking forward to another year of great discussions on the profession we all love!

Kupe

Don’t forget to leave your comments below

Jonathan “Kupe” Kupersmith is Director of Client Solutions, B2T Training and has over 12 years of business analysis experience. He has served as the lead Business Analyst and Project Manager on projects in various industries. He serves as a mentor for business analysis professionals and is a Certified Business Analysis Professional (CBAP) through the IIBA and is BA Certified through B2T Training. Kupe is a connector and has a goal in life to meet everyone! Contact Kupe at [email protected]

Reinventing the Program or Project Portfolio Chart

Written by Mark Jenkins on December 1, 2009. Posted in Articles.

The fourth and final part of my “Reinventing…” series (which ran in Business Analyst Times earlier this year; see links at end of article) concentrates on a project portfolio rollup chart. Since this charting technique also includes and tracks business priority, I call this communication tool the “Project Barometer”.

As with the previous articles, the chart attempts to maximize the amount of information a single diagram can communicate, without overwhelming the reader. However, unlike the previous techniques, which required the use of Visio, the barometer takes advantage of the simplicity of Excel.

For a BA who is actively involved in managing an IT to business relationship, questions regarding project status and upcoming effort are common. I use updates from my team as well as updates from other groups to collate a chart that helps to quickly respond to such prompts as, “What are you guys working on?” or “What is the priority of this project?” by providing relevant information at-a-glance. The aim is not to provide a detailed breakdown of the status of each project; that is better left to your project management team, but to use the Barometer as a communication tool to assist a stakeholders understanding of your IT program at a macro level.

The development of upcoming priorities is also something the barometer tracks effectively; my BA team is also tasked with managing the upcoming IT workload, forming a demand queue through turning stakeholder ideas into project proposals. As such, we use the Project Barometer to help prioritize these stakeholders’ ideas, which we then communicate to the IT management.

Lending a greater level of visibility before a project gets off the ground, the Project Barometer helps individual departments to align themselves with and keep focus on current efforts.

A key part of the BA role is to pinpoint areas of project neglect (areas where a project may have missed stakeholders or scope, downstream impact, etc.). This tool has proved extremely valuable, both in department reviews and, in a more proactive sense, for stakeholders or departments to view at will. I have also found this technique equally appealing to executives and individual contributors for the facile communication and information transfer it procures. Without the Project Barometer chart, our BA team would not be as effective.

When designing this chart, I thought about some of the common problems faced by IT employees, managers and business stakeholders. Typically, project status updates take the form of multiple page documents, PowerPoint presentations and/or meetings to deliver this information, which can be difficult to navigate and time consuming. Although highly detailed reports serve a valuable purpose, the Project Barometer extracts relevant information from those reports and organizes it in a simple, unambiguous chart made accessible to all involved parties. As response to questions regarding status, priority, and effort, the Project Barometer provides immediate information in a concise, visual manner. Such an at-a-glance informational tool becomes ever more important the higher up the corporate ladder you go.

With those parameters in mind, I wanted to find a way to fit an entire program status on a single page. The Project Barometer is a result of these efforts.

View Larger

My barometer consists of 11 columns, which, in order from left to right, track priority, project name, project status, effort and the stages of the SDLC.

The rows are filled with the individual projects grouped together by department. The Sales and Marketing groups are shown here, each separated by the blue bars.

Within each cell, a coding scheme is used to communicate relevant information, I include a legend at the bottom of the barometer but, for the most part, it is self explanatory.

View Larger

In this next part of the article, I’ll provide a step by step guide to building your own barometer.

The easiest way to begin is to list all of your projects currently in progress. For each project, think about the amount of effort involved and which group owns which project. The grouping of projects by department is one of the things that make the barometer useful.

At the end of this effort you should have a list of projects, grouped by department and assessed for effort, such as the example below.

The next step is to think about the stages you track in your SDLC, typically it will be something like the completed barometer shown above, but because Excel is so easy to use, you can adjust the columns as required.

View Larger

It is now a simple exercise to add either the date the stage was completed or the percentage of completed progress to the individual cells.

View Larger

It would be reasonable to stop here and have a functional chart, but as we saw above, there is more information we can communicate. In order to make the chart easier to read, I grouped the projects together by department. To do this I simply merge a row of cells and then, for each section, add and repeat the headers. Moreover, I add the key stakeholder for each department; this is the person you would work with to set the priority of each project.

View Larger

To communicate a clearer idea of progress, we can apply colors to the stages. We’ll follow the standard traffic light format, green for good, amber for minor issues, red for major issues. If a stage has been completed, I always set it to green.

View Larger

During my barometer design, at this point I didn’t feel like the chart was providing as clear a picture as possible because I had all the stage progresses annotated the same way. It makes it hard to differentiate, at-a-glance, between completed and in-progress efforts. To eliminate this problem, when a stage is completed, I change the text color to a light green. This has the effect of making the white, in progress stage, stand out more. As you progress to making larger barometers with a greater number of projects, this effect will become more vivid.

View Larger

We now have a completed diagram mapping the current program status, but what about priority? What about upcoming ideas? As I demonstrated above, this can be built into the same diagram with minimal effort. To tackle priority, I simply add two columns, one labeled “Priority” which tracks position (position one should be the most important project to the stakeholder), and the second column labeled “Movement,” tracking any priority changes. The addition of these two columns makes the barometer a great negotiation tool. Combining the Project Barometer with the Resource Chart forms a powerful arsenal of persuasion, with the odds stacked in your favor.

Dealing with the practicality of keeping the chart current, if a project is added with a higher priority than existing efforts have or a project priority is downgraded, I generally only show the movement of the added or downgraded project (i.e., I don’t show the shift in movement through the list of each of the others).

View Larger

Adding and prioritizing upcoming ideas or requests is also easily facilitated. Add an extra column for status, add the ideas and then update as needed. You could also track any kind of status here. You may have a designation for small projects and large projects, for example.

View Larger

The diagram is now nearly complete, once the version and date range are added. I typically update at least three times a week.

In summary, we have again created a simple but highly readable diagram to demonstrate the current status of projects and ideas, and in so doing, provide a complete picture of the program.

I’ve received some positive feedback on this series of articles, so thank you for taking the time to read and reply with your comments. In the majority of emails, I receive requests for a template. Now that I have finished the series, I’m working on bundling the templates and stencils into something you can all download.

http://www.batimes.com/component/content/article/106-articles/453-reinventing-the-swim-lane-diagram-part-1.html

http://www.batimes.com/component/content/article/106-articles/463-reinventing-the-swim-lane-diagram-part-2.html

http://www.batimes.com/articles/106-articles/490-reinventing-the-resource-chart.html

Don’t forget to leave your comments below

Mark Jenkins is Manager Business Analysis Group at Websense. Mark has spent the last year establishing this formal business analysis group that now plays an active role in all major business projects at Websense. As part of the development, he created new process and documentation standards, which assisted in the overhaul of IT Project processes, placing the BA Group at the forefront of the IT to business interactions. He can be reached at [email protected] and on twitter www.twitter.com/JenkoUK

Can a Person Function as both BA and PM on the Same Project?

Written by Elizabeth Larson on November 24, 2009. Posted in Articles.

One of the most frequently asked questions I still get from my clients is whether or not one person can be both a PM and a BA on the same project. The answer, of course, is yes, they can. A related question, though, is whether or not they should. I think there are really two different answers to two different questions.

If the question is could the BA and PM play the same role on the same project, my answer is that I can think of many situations where a single person could perform both functions. For example, if the organization does not recognize the importance of either role, if it doesn’t have enough resources for both roles, if a project is known to be “small,” when the team has worked together and is a high-performance team, one person could play multiple roles. Functioning in both roles on one project can work, especially when it is clear to everyone which “hat” is being worn at any given moment.

On the other hand, we might ask under what circumstances would it make sense for the BA and PM to play the same role. For me this is a harder question to answer. Here are some considerations:

Generally speaking, there is an inherent difference of objectives between the two roles. The PM’s role is to meet the project objective (PMBOK® Guide Fourth Edition Section 1.6). The BA’s role is to help organizations to reach their goals (BABOK® Guide 2.0 Section 1.2). This is a subtle but important difference. Organizations usually complete projects to help them meet their goals. Project objectives are more specific than organizational goals. Put another way, the project objectives help the organization meet its business goals and objectives. The PM focuses on the former; the BA on the latter.
Another difference is one of focus. The PM typically focuses on the project-creating baselines and managing project constraints, communications about the project, resolving issues about the project, getting the resources working on activities and tasks. The BA typically focuses on the end product. However, those lines are not always clear- cut. According to the BABOK® Guide 2.0, BAs do need to focus on the project when they plan and monitor the business analysis work, which is part of the project. That is, planning how the business analysis work will be completed, how formal the work will be, what documents, if any, will be produced, what approach will be taken, how the work will be tracked and reported etc. is project work. The focus is on the project, not the end result.
However, doing project work as part of business analysis does not mean that the roles of PM and BA overlap. The project manager gets input from a variety of people on the team including the BA and uses that information to manage the project.

Although the PM may do some work related to the product and the BA may do work related to the project, there is still a need, I think, for both roles on most projects. It seems to me that:

It takes time to do both jobs well. Certainly on “large” projects, it is a full-time job to manage the project and to manage the end product requirements. Trying to do both will usually mean increasing the risk and compromising the quality of both the project and the end product.
One of our clients recently completed a study on separating the two roles, which had previously been combined. This assessment was undertaken in part because during different phases of the project, the PM role was neglected, and during other phases the BA role was. They concluded that on most projects both roles were needed and recommended the separation.
Because there is a different focus and different objectives, there is often a pull in opposite directions, especially when both roles report to different organizational functions. Project managers want to deliver the end product on time and within budget. Business analysts want to ensure that customers can actually use the end product once it has been implemented.
I can almost hear an internal conversation the combined PM/BA might have: the PM voice, sitting on one shoulder, says “But this has to be complete by Jan. 15^th so we need to take these shortcuts.” The BA voice, sitting on the other shoulder, says “But we need to take time to do this right. If we put this into production now, it will cause defects, rework, workarounds…” The PM voice replies “if we don’t meet the date, we’ll destroy all their trust in us.” The BA voice says, “If we don’t get this right, we’ll destroy all their trust in us.” When we wear multiple hats, which voice do we listen to?

Personally, I have found it helpful to have both roles on projects, even when the project is “small.” So although it may not be necessary to have both a PM role and a BA role on every project, it sure makes sense on most.

Don’t forget to leave your comments below.

Elizabeth Larson, PMP, CBAP,CEO and Co-Principal of Watermark Learning (www.watermarklearning.com) has over 25 years of experience in business, project management, requirements analysis, business analysis and leadership. She has presented workshops, seminars, and presentations since 1996 to thousands of participants on three different continents. Elizabeth’s speaking history includes, PMI North American, EMEA, and Asia-Pacific Global Congresses, various chapters of PMI, and ProjectWorld and Business Analyst World. Elizabeth was the lead contributor to the PMBOK® Guide – Fourth Edition in the new Collect Requirements Section 5.1 and to the BABOK® Guide – 2.0 Chapter on Business Analysis Planning and Monitoring. Elizabeth has co-authored the CBAP Certification Study Guide and the Practitioner’s Guide to Requirements Planning, as well as industry articles that have been published worldwide. She can be reached at [email protected].

Business Analysts Need to be Project Managers

Written by Kupe Kupersmith on November 24, 2009. Posted in Articles.

I know what you’re thinking. Kupe has lost his mind…he’s a flip-flopper! In my last post, What?! You Don’t Want to Be a Project Manager, I gave my view on why companies need to have career paths for their BAs other than to become a Project Manager. I sit here today still defending that position. But, I do feel BAs with project management experience have a slight advantage. As some of you know, earlier in my career, I went from an accountant to business analyst. What you may not know is I took a project manager role at one point in my career. I was one of those new guys trying to move up that company ladder and thought all my happiness would come from being a PM. Wrong! The good part of that experience was that I was formally trained and had the opportunity to work with a great mentor. My last year and a half as a PM I had to play both roles, PM and BA. I found myself spending more time on the analysis side of things, therefore neglecting some important PM tasks. It was at that time I realized my true love was business analysis. I found an opportunity to go back to business analysis full time and never looked back.

With every situation I try to find the positive. For me, gaining PM experience made me a better business analyst. In the spirit of this week’s US holiday, Thanksgiving, here are the top three reasons I am thankful for being a project manager.

Planning

I am thankful for understanding the basic concepts of a work breakdown structure. As business analysts, it is our responsibility to plan our activities. Then working with the project manager our plan gets incorporated into the overall project plan. When developing my plan I am able to layout my schedule with proper dependencies and include adjustments for my working time and my stakeholder’s working time. With the help of MS Project I can see where I need to add or where I can reduce time. For this I am thankful that I have PM experience.

Project Lifecycle

I am thankful for understanding the full project lifecycle. As business analysts, everything we do impacts all phases of a project lifecycle. As a PM I was able to get better insights into the needs and challenges for development, testing and implementation. Every project we work on is a change to the people for which we implement solutions. As a PM, I learned to work closely with the business stakeholders to develop strategies to help the user community implement and adjust to the new or enhanced system. For this I am thankful I have PM experience.

Leadership/Motivation

I am thankful for being able to lead and motivate teams. As a business analyst and a project manager, you have to lead and motivate without authority. My approach as a project manager was to lead and motivate by building a strong trusting team. By coming together early in the project and determining the tasks needed to accomplish our goals, everyone was bought-in to the project approach. Together we were accountable for our successes and failures. As a business analyst, I find the need to motivate my business stakeholders to participate in the analysis approach every now and then. In my post, Mr. Business Analyst, You’re Not a Good Fit!, @gbusby commented that a senior level BA role requires selling. I agree 100%. Many times stakeholders still want to give a few statements about their needs and then let the project team work their “magic.” That approach almost guarantees failure, so we need to find creative ways to get these stakeholders to fully participate. As a BA you may not be leading the entire team, but at senior levels you will find yourself leading a team of BAs on a project. You need to be able to lead and motivate this group. For this I am thankful I have PM experience.

Even though I do not want to be a project manager, I found my experience helped me become a better business analyst. What role(s) did you have in the past that helped you become a better business analyst? What are you thankful for?

Thank you for reading and leaving your comments,

Kupe

Don’t forget to leave your comments below

Jonathan “Kupe” Kupersmith is Director of Client Solutions, B2T Training and has over 12 years of business analysis experience. He has served as the lead Business Analyst and Project Manager on projects in various industries. He serves as a mentor for business analysis professionals and is a Certified Business Analysis Professional (CBAP) through the IIBA and is BA Certified through B2T Training. Kupe is a connector and has a goal in life to meet everyone! Contact Kupe at [email protected].

What?! You Don’t Want to Be a Project Manager?

Written by Kupe Kupersmith on November 10, 2009. Posted in Articles. 1 Comment on What?! You Don’t Want to Be a Project Manager?

In my last blog post, Mr. Business Analyst, You’re Not a Good Fit!, I discussed three characteristics you should look for in a business analyst. It sparked great conversation and some of the comments inspired this blog post. I stated one of the characteristics hiring managers should look for in a BA is passion for the BA profession. A reader commented, in so many words, that if they feel a candidate is looking for a BA role to get their foot in the door so they can get a PM role later, they shy away from them. Another reader has a manager that wants her to take the PMP exam because it is more popular.

These comments reminded me of what I was up against earlier in my career. A company I worked for had a career path where a Sr. BA “grew up” to be a Junior PM. Many companies still have this approach, and I stand here today saying “this needs to change!” This is a clear indicator of the lack of understanding of the role and/or value an organization puts on the importance of business analysis. In this post I want to highlight the impact on an organization with this career path.

BAs Stop Being BAs

Once a BA is promoted to a senior level all the good stuff starts to happen. It’s like a properly aged wine. At this point, the BA has had enough experience to feel comfortable on most projects and can be a valuable mentor to junior BAs. Unfortunately the BA does not age as anticipated when their next promotion is to a project management role.

What do people do shortly after they get promoted? They look at the next level and see what they need to do in order to prove that they can do that job. If a Sr. BA’s next step is project manager, they will tend to focus more on PM related activities and not as much on the business analysis side. An impact is that organizations always have more junior level staff performing most of the business analysis work. This leads to less than stellar analysis, customers are not satisfied and projects are less successful. The impact is huge in terms of customer satisfaction. I have seen this happen, it’s ugly.

All BAs Do Not Want to Be PMs

Some BAs want to be PMs and I think that is wonderful. Personally, I love when my PM has business analysis experience. So, a target for BAs should be a PM role, just not the only one. If it is the only one, organizations end up only with people in that role that do not want to be PMs. By nature, people want to move up that ladder. They’ll do what is necessary to convince management that they want to be a PM, but they’ll be miserable.

This leads to less than stellar project management; customers are not satisfied and projects are less successful. Do you see the pattern? I did an informal survey two years ago and asked BAs with a PM only career path if they wanted to be a PM. Of the 30 I asked, six said yes. That’s just 20%…yikes! But, almost all of them would take the promotion because it meant more money and a notch up the ladder.

Other Options

That the PM route should not be the only career path, it is only fair I share my thoughts on otherr options. They’re not straight forward and, unfortunately, may give HR professionals heartburn. A big factor is the desires of the individual BA. With a BA skill set (problem solving, analytical thinking, facilitation, consensus building, focus on business value, relationship and team building, etc.) individuals can take one of multiple paths. For those that want to be in the IT space, a potential path can be Jr. BA, Sr. BA, BA Lead, BA Manager, Director, VP, CIO. Additionally within IT, BAs can move into a business architect position and/or strategic business analysis role where they look across the company to help determine the best projects to pursue to maximize business value. BAs can also move into the lines of business. As a BA you gain valuable information about the business goals, operations, and areas for improvement.

In the end, individuals with a BA skill set have more to offer than just becoming project managers. I also believe BAs with project management skills are better analysts. A future post will address that concept. Organizations need to offer BAs a variety of growth options to maximize their skills. Having a single path can lead to a less productive workforce and attrition. BAs who don’t want to be PMs will eventually leave.

To our continued growth,

Kupe

Don’t forget to leave your comments below