Tag: Planning

Change Management; What Exactly is Buy-In?

Written by Kelly Burroughs on October 27, 2009. Posted in Articles. 1 Comment on Change Management; What Exactly is Buy-In?

When it comes to change management, the term ‘buy-in’ is tossed around the office like a baseball around the diamond in a pre-game warm-up. It is a term used to indicate the need to convince everyone to get on board the change train, as it is destined for great things. But I find this term funny, because it indicates the change has already been decided, the train is leaving and I better get on or…well stay behind. And then we wonder why there is resistance to change.

But what if change was not something that was imposed on people, but was something they themselves came up with?

So many times I have worked on a project where a decision is made at an executive level, and then announced to the business with a fancy PowerPoint slide show, a few bullets about what the benefits will bring, and the overall concluding message of “we are doing this regardless, so you better get on board”. And then we wonder why there is resistance to the change. But the fact is, if you make the decision to change without first asking the people the change will affect most, chances are pretty good there will be a defensive and resistant reaction.

One example that comes to mind is a company that decided to reorganize the entire organization without telling the employees until a company wide meeting was called one morning. Employees shuffled in, took their seats and found staring back at them, a man dressed up in a bear costume and fireman’s helmet, there to put out the ‘fire’ (and make the PowerPoint presentation). Needless to say, the reaction from the employees was not a good one (and going into the many reasons why might just be another article all on its own). In the end the meeting was not a productive one and, in fact, put many employees on the defensive about their job security and their role within the company. Everyone left more confused than when they had arrived, and nobody remembered any of the benefits listed within the PowerPoint presentation (but will probably remember the bear costume for life!).

But what happens if you skip the fancy PowerPoint slide show, and get the non-IT folk to come up with the idea in the first place? Would there still be resistance?

People have a tendency to want to own things – whether it be their house, car, yacht, or the job they perform on a day to day basis. Because to many people a job is a set of daily routines and procedures they have become accustomed to doing on a daily basis; and more than that, have become very good at. To then introduce change into that daily routine without consulting or involving them, is the equivalent of stealing their car from their driveway and trading it in for something new, without asking them. Now some people might be happy with a new car, but many people would resist the new car and want their old one back. Maybe they wouldn’t like the colour because they didn’t pick it, or maybe they didn’t really want the upgrade to a sunroof because they once had a bad experience sticking their heads through one. Maybe they just did not like the fact that the decision to get a new car was not theirs. And there is no difference with change in the workplace. If you just suddenly take something away from somebody and replace it with something that you may think is better, you can almost be guaranteed they will find something wrong with it, and NOT think it better.

So then, how should change be introduced?

How about driving the change from a lower level? With so many change initiatives coming from the top of an organization, you constantly have a top-down channel of communication, which often puts those on the bottom on the defensive. How many times have we heard in reaction to a change: “Why do we need that? What is wrong with the way I do my job now?’ But what if what if those who would be most affected by the change were approached at the start and asked things like:

So what currently holds you up in your job?
Is there anything you do now that is completely manual?
Is there anything in the current process that you think should be changed which might make it easier for you to do your job?
Would you like to be involved in looking at new software for what you do?

Would they then see it as change, or would they maybe see it as something they can own, or do, to improve their jobs?

To me, getting others in the business to see the issues, own the issues and then, because of it, want to be part of the solution is the key to incorporating change into a company. It is surprising how often people are willing to be a part of projects, if they are just given the chance to get in at the start. But to be just told they are on a project, which ultimately affects their job, is often times a setback right from the beginning.

There will always be those who think making the decision and then showing the fancy PowerPoint presentation with the benefits of the solution is the answer to introducing change. But to me, change should never have to be introduced to the business – it should be generated upwards from the business. Getting people to realize the problems themselves, and come up with the solution themselves, will almost always work because people take pride in what they own and want to make their ideas work. Because remember; there is very little difference between ‘change’ and being ‘creative’. The only difference lies in where the direction comes from. You tell somebody to do something and they cringe at ‘change’, but if you get them to come up with the idea themselves they are ‘creative’, and will take pride in being so.

Don’t forget to leave your comments below

Kelly Burroughs is a Business Analyst/Project Manager for Halsall Associates, a professional services engineering company. She has several years experience in implementing larger scale technology changes into businesses, as both a business analyst and a project manager. She can be reached at [email protected].

Is the Business Analyst’s Work Ever Done?

Written by Jill Liles on June 9, 2009. Posted in Articles. 1 Comment on Is the Business Analyst’s Work Ever Done?

Solution Assessment and Validation

The business analyst’s work is not finished when the requirements document is signed off. Although other experts are responsible for the project activities, the BA remains involved to ensure that decisions made have no adverse impact on the business stakeholders. As the project moves forward, the BA should collaborate with the solution team (for example, development, procurement) to ensure that the final solution will satisfy the requirements.

After the solution has been built, the BA collaborates with many people on activities such as testing, conversion, cutover, and training. Depending on the roles defined in an organization and the project, the BA may collaborate with the people who are responsible for these activities, or the BA may be the responsible person. In either case, the BA ensures that all of the right things happen.

Monitor Solution Design and Planning

As the technical team derives the solution design, the BA must learn enough about the implications of that design to ensure that it supports the requirements well. For example, the BA might:

Review user classes to ensure that all of the solution functions, uses, and end users have been accounted for.
Review the developers’ functions and feature list for completeness.
Map the documented requirements (both functional and Quality of Service) onto the elements of the system design to ensure complete coverage.

When the technical team defines its phasing plan (which identifies the order in which requirements will be addressed and functionalities designed and built) for incremental development, the BA must ensure that the plan supports the stakeholders’ needs. If the plan calls for features to be delivered in a certain order, the BA should ensure that the planned order and delivery dates would be useful to the business stakeholders. The BA should also ensure that the phasing plan provides opportunities for any needed prototyping or validation during the project.

Tracing the requirements to the design is a good way to ensure complete coverage, and it lays the foundation for maintaining traceability throughout the project. The traceability information must be captured and recorded as the designs are being done, as trying to derive the traceability after the fact is difficult, if not impossible.

Finally, as the solution is being designed and built, the BA may identify business process improvements that are unrelated to the solution but that would be beneficial. This is especially likely where those processes will be affected when the solution is implemented.

Validate the Final Solution

As each deliverable of the project becomes available, the BA must ensure that appropriate validations take place to ensure that those deliverables satisfy the requirements and can be used by the intended end users.

System testing looks at the final system to determine if the requirements have been satisfied. System integration testing refers to testing the final solution to ensure that it can coexist and integrate with existing systems and databases. Many organizations have an independent testing group whose main responsibility is to prepare for and perform these tests. When that is the case, the BA will usually review the test plans and the test results, and at times, the BA may help with the testing. However, in organizations that don’t have testing groups the entire responsibility falls to the BA.
Operations testing involves testing the final solution to ensure that it can be installed and run without an adverse effect on the other existing systems. If the computer operations group takes responsibility for this testing, then the BA will usually review the test plans and the test results. But if this testing is necessary and no one takes responsibility for it, then the entire responsibility for this testing falls to the BA.
Acceptance testing ensures that the business need and user’s needs have been fully satisfied. If the customer takes responsibility for this testing, then the BA will usually review the test plans and the test results. Otherwise, the entire responsibility for this testing falls to the BA.

Assess Other Solution Options

The BA should collaborate with a variety of people on the project as the solution is being put together. In all cases, expect the experts in each area to be making good choices. The BA’s role in the collaboration is merely to serve as the business stakeholders’ advocate and assure that their needs will ultimately be met.

Although the technical team takes the lead in evaluating and deciding on the technologies that could be employed to build the solution, the BA should remain involved. This is because every technical choice has the potential to cause limitations in the final solution that will be noticeable to the users. So, the BA must learn enough about the effects of the team’s technical choices to ensure that they actually do support satisfying the requirements, and ultimately, the business needs.

When the plan involves purchasing or leasing (as opposed to internally developing) a solution, the BA may take the lead in choosing the solution. But even if someone else has primary responsibility for this, the BA will still remain closely involved. The BA ensures that any RFP (request for proposal) or RFQ (request for quote) accurately translates the requirements. The BA should also verify that the proposals received will fully meet the business need. And, when the solution is finally received, the BA ensures that it is adequately tested to be sure that is actually satisfies the requirements.

Support Implementation of the Solution

In some organizations, an operations team takes the lead in implementation, but often the BA is responsible. In either case, the BA must remain involved to ensure that implementation and any necessary conversion meets the needs of the users.

The BA ensures that any necessary installation planning is done, and that the appropriate technical experts review that plan for correctness. This could be as simple as ensuring there is enough disk space for the new software, or as complex as replacing entire computer systems with new ones.

Conversion is almost always an issue. Since the solution is most likely changing some attribute of the business process, there will probably be data conversion; there may also be other kinds of conversions to be done. Planning for these includes identifying the rules for handling the inevitable problems that will be found.

Finally, the plan to the final cutover to the solution must be well thought out. When should it happen? Will there be downtime involved? If so, how much is acceptable? An important, but often overlooked item is the “backout” plan. If the cutover fails, what must be done so the business can resume working with the old system? If there is significant data conversion or other changes, this can be a difficult problem.

Communicate the Solution Impacts

The responsibility of communicating the impact of the final solutions is assigned to different people in different organizations. In any case, the BA must still remain involved. Before the new solution is implemented, the BA should work with the business stakeholders to ensure that they are ready for it by:

Ensuring that everyone who needs to know about the implementation has the information they need, when they need it, before implementation
Setting the expectations of users and other stakeholders about how the change will affect them and the business process
Making sure that any needed training and help is available to the users in a timely manner

After the implementation is complete, the BA collaborates with the appropriate people to report on the implementation. This reporting provides pertinent information to all the parties who need to know that the implementation took place, and if there were problems. A key item is the business impact that the change had. Since the project was undertaken to improve a business process, the actual impact on the business process is of major concern.

Perform Post-Implementation Review and Assessment

The final validation occurs after rollout of the solution is complete. This activity, also known as “Lessons Learned,” is designed to help the organization learn from each project, supporting continuous process improvement.

You need to capture these successes, identify why they happened on this project, and determine what can be done on future projects to make them routine. The parts of this project that worked particularly well represent opportunities for future projects.

By the same token, if there were things on this project that were problematic, they also represent opportunities for improvement. You need to capture these issues, identify why they happened on this project, and determine what can be done on future projects to avoid them.

The Lessons Learned review is one of the most potent mechanisms for organizational learning and continuous improvement, as long as you actually use what you learned in future projects.

In Summary

Solution assessment includes all the activities that the BA collaborates in to ensure that the technical and other decisions being made by the development team result in meeting the needs of the business and users. These activities include design decisions, phasing for incremental development, maintaining the traceability matrix, choosing technologies, procuring solutions, and ensuring usability.

Jill Liles is the Senior Product Marketing Manager at Global Knowledge http://www.globalknowledge, where she primarily focuses on marketing activities for Cisco training courses. She also coordinates all marketing for Canada. In her spare time she volunteers with her local Susan G. Komen Foundation affiliate and crafts jewelry. This article draws from Global Knowledge’s Requirements Development and Management course.

Avoiding Conflict between the PM and BA. Part 2.

Written by Elizabeth Larson on June 9, 2009. Posted in Articles. 1 Comment on Avoiding Conflict between the PM and BA. Part 2.

Planning Business Analysis Work

When I first read the BABOK® Guide, my initial reaction was, “What are they thinking?!” With my PM hat perched squarely on my head, my reaction was “but… but this is PM work!” In my mind I imagined all kinds of conflict occurring as the BA took on more and more of the PM role. After all, as a PM I had done such traditional project management tasks as creating work breakdown structures, activity lists, estimating, scheduling, and now a body of knowledge was saying that the BA was supposed to do this work? I could see heads butting already.

When I joined the BABOK committee about a year later and raised these concerns, I was asked an insightful question: “Elizabeth,” one of the committee members asked, “as a PM did you come up with all the deliverables, tasks, and estimates for everyone on the project?” Ah, BAs sure do ask good questions! I remembered that as a PM I had gone to many team members, in particular technical SMEs, the developers, our full-time business SME on the project, and others to get their deliverables, tasks, estimates, and availability. But it had never occurred to me to involve the BA. With that one question the light bulb came on. The image of locked horns disappeared. In its place I saw a PM (me) with the weight of too much project planning on her shoulders suddenly stand up straight and unencumbered. How much easier my life as a PM would have been if for the business analysis work, I had taken the information from the BA and rolled it into the overall project. What a relief it would have been to get the business analysis input from the person who knew the most about business analysis!

With the light bulb came a few related insights:

Planning doesn’t mean doing all the work yourself, so PMs don’t have to complete all the planning processes listed in the PMBOK® Guide themselves. PMs need to ensure that all the work appropriate to the project is done, but that does not mean that the work in Section 5.1, Collect Requirements, for example, must be completed by the PM.
BAs are closer to the business analysis effort, so input from BAs is apt to be more complete and correct. When competent BAs are on the project, PMs do not need to micromanage business analysis. There’s enough for PMs to do, so getting out of the way during business analysis will likely reduce the PM’s stress. PMs, so focused on delivering on time and within budget, need to realize that PMs and BAs working collaboratively get more done, so the project has a better chance of completing sooner.
On large projects, both the PM and BA have full-time work doing project management and business analysis respectively. If either is saddled with doing the work of the other, both will be overburdened, increasing everyone’s pressure and stress levels. Under such circumstances, resolving the inevitable territorial conflict will be that much more difficult and take that much more time, delaying the project even further.

So my advice, PMs, is to let the BAs do business analysis work, which includes business analysis planning. My advice, BAs, if confronted with a PM who wants to plan for the entire project, is to keep asking those insightful questions!

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]

Why Visualize Requirements?

Written by Genefa Murphy on May 19, 2009. Posted in Articles. 2 Comments on Why Visualize Requirements?

How many times have you been in a meeting discussing a set of requirements, a methodology, or a project plan etc and someone has gotten up from their chair and said “where’s the whiteboard let me draw what I mean”?

I can tell you for me it has been plenty!!!!

Whilst requirements specifications are a great way to document the detailed information related to a new or existing product’s functionality we all live in a time poor society and few of us have the time to trawl through large documents and extract the information we need and then start the seemingly endless e-mail threads to discuss the individual use cases associated with each requirement consisting of many messages that start and end with “what did you mean by X?”, ” I meant X and Y but I think you thought I meant Z!” Instead why don’t we adhere to the adage of a picture tells a thousand words and instead of page after page of documents create a visual representation of those requirements – hopefully communicating a thousand words in a single picture.

However, what we must remember is that visualization of requirements can vary in its meaning. For example, some people may view requirements visualization in the same context as simulation diagrams, whilst others interpret visualization to mean simple use case diagrams or business process flows typically created in a MS Visio type tool. For me, all of these usage contexts can represent visualization, so instead of trying to classify visualization into one genre I thinking it is best to view it on a scale with simple flows at one end and high end simulations at the other – and the user selects which method is most appropriate for them at any given time. For example, if you are trying to show how a user will move through an application to make a purchase then using MS Visio to define process flows may be enough. However, if you are trying to envisage how a new UI (User Interface) may look then mockups and more rich content visualizations would serve you better. Whichever method is selected there are a number of benefits that come from visualization these include:

Flexibility and Usability – flow diagrams can be easier to navigate helping to find content
Mistakes can be easier to identify in a visualization
Easier to identify potential parallelisms between requirements and business processes
Easier to spot missing Use Cases in business process
Increase understanding of the requirements themselves
Increase understanding of the dependencies between requirements
Visualization of business flows can provide a first bridge to Business Process Models or SOA repositories

Now that we have explored some of the benefits of visualization the question now becomes when should it be used? Should we visualize every requirements we write or just some and if we are going to be selective which requirements should we chose?

In my opinion there are a number of questions we can ask ourselves which can help to determine when to and when not to visualize. These include (and there are many more):

Type of development method – we need to ask ourselves the question do requirements visualizations fit in with the need for more agile and rapid requirements definition or will they add more time to the development process?
Complexity of the requirement – if a requirement has too many sub requirements will this create a “spiders web” diagram which may overcomplicate the definition of the requirement?
Type of requirement – should we visualize the user story only and define the functional requirements associated with this user story as text or do we want to visualize all requirements?
Risk level of the requirements – should only high priority or high risk requirements be candidates for visualization?

It is important to note that I am not saying that requirements visualization is a “panacea” for enabling effective business and IT communication but what it will do is act as a good facilitator to help initiate a better degree of communication and understanding between the two parties.

So now the decision is yours. Why not try visualizing requirements and feed back to the group how things go.

Genefa Murphy works and blogs with Hewlett-Packard where she is Product Manager for Requirements Management. This article first appeared in HP Communities.

The New Role of the Business Analyst and The Strategic Implications

Written by Cynthia Low on March 9, 2009. Posted in Articles.

The new role of the BA is far more strategic in both the organizational sense as well as at the project level. In fact, I would go as far as to say that the BA, when appropriately leveraged, represents a liaison between business, project and customer teams. This shift in responsibilities identifies two areas that need to be addressed by any organization seeking to expand this role:

The organizational structure must support the actions of a “strategic” BA position.
The BA candidate must have wide skill sets, encompassing many general management competencies.

As organizations shift to become “projectized,” the roles and responsibilities that have supported projects within a traditional matrix structure must shift as well. Over the years we have seen organizations struggle with the following challenges related to shifts in both structure and culture:

Broken or disjointed cross-functional communication channels.
Uncertainty around roles and responsibilities within the project structure and beyond.
Quality concerns at the point of project delivery.
Skewed scope statements and, thus, implementation plans due to early-stage breakdown.
Overall loss of productivity on project teams due to lack of continuity and methods.

The items noted above are tell-tale signs that several strategic components of a best practice project management environment are missing. In the past, we addressed the discussion around project office and methodology; the topic of BA is an integral component to bring both of those items to life in the real world.

Forward looking or best in class organizations have aggressively embraced the concept of the BA role. What sets them apart from the old school thinking associated with this job title is the escalation and expansion of the roles, definition and responsibilities. Not too many years ago, a BA may have been confined to a very technical role within an IT environment working on specifications, functionality and even some quality and testing related to one or more project life cycles. Today we are seeing BA positions filled from across the organization and expect that this trend will continue, as it should.

Let’s address these points in the context of how they can be leveraged to meet the challenges:

Broken or disjointed cross-functional communication channels

A BA should be in front of any project communication produced, from the point of team inception to the close-out phase. This interaction does not mean that the BA takes on the role of project manager (although we have seen organizations combine the two roles), as it is not effective on larger and longer term initiatives. Our experience shows that an independent BA position can help to promote better communication, align protocol and help the project manager to extend his/her reach into the project teams.

Uncertainty around roles and responsibilities within the project structure and beyond

The BA functions as a tour guide through the project plan ensuring that all of the moving pieces are touching at the right points. We call these critical communication points and they can be built around time, budget or deliverable expectations. The BA will be assigned a protocol map within the project structure to enable better access to expectations, and provide for a proactive way to reach team members.

Quality concerns at the point of project delivery

In reality, the BA is monitoring quality points through the project life cycle, thus producing a quality product at the close of the project. Very much like the thinking around proactive quality control, the BA is in front of each deliverable and monitors the progress against the project plan. This allows for immediate communication between the project manager, customer and associated teams.

Skewed scope statements and thus implementation plans due to early stage breakdown

The planning stages of a project are obviously critical to the implementation plan and ultimate quality. A BA should be assigned early in the process and work hand in hand with the project manager to ensure the highest level of intimacy with the plan. Just as important, they need to have a direct connection to the internal and external customers in order to ensure collaboration and proactive attention to emerging issues.

Overall loss of productivity on project teams due to lack of continuity and methods

A strategic BA assists the project manager and PMO with the execution of best practice within an organization’s project management structure. The BA has a unique opportunity to guide the process through an existing methodology and essentially help the project to operate in better alignment. This is accomplished by having a dedicated individual who is consistently working against the deliverables and is not distracted by the operations management associated with the project manager’s job.

By taking the above steps you have begun the shift toward the organizational structure needed to take advantage of the BA position. With that said, we still have one more change to make in order to secure success.

It is obvious that the BA role, as defined here, will require wider skill sets than the more traditional BA position, still driven from the IT departments of yester-year. To that point we have begun to see a trend where the BA position can spawn from either business or IT. This is an interesting point as it speaks volumes to an organization’s maturity around project management. Imagine, for just a moment, an organization that has no boundaries within in its functions and everyone on the team collaborates toward a common goal. I like to call this organizational desegregation and cultural morphing. As we begin the next phase of benchmarking the project management industry and clients, we are beginning to see this shift as a representative of the next wave of advancing thought in the project management space. It was not too many years ago that I published an article on the emerging role of the project manager as the CEO of his/her project. I am confident that the BA role will take a firmly positioned spot in the upper hierarchy of any world class project organization within the next few years.

In order to succeed the BA will need to have a competency profile that meets the following criteria:

Excellent understanding of both business and technology within the project environment.
Be a leader, communicator and professional.
Understand the skills associated with internal consulting techniques.
Be proficient in project management skills as well as a complete understanding of the internal process.
Epitomize the essence of a collaborator and team player.
Understand and be able to navigate through the organization’s politics and structure.
Be able to manage without having authority via negotiation.
Understand true stewardship-based service.

So, the BA role probably looks a little different than a traditional structure may have dictated. Yet, this is the trend and, I believe, will become the norm. As organizations look to enhance productivity and quality while reducing cost, they are finding this role to be extremely important. Additionally, project managers we spoke to during the research for this article all stated that having a BA on the team made their job easier, and allowing them to focus on deliverable based activity.

It is important to note that this type of structure is recommended for mid- to large-size projects, but on the smaller initiatives we found that these attributes were part of the project manager’s role.

Phil Ventresca is Founder, CEO and President of Advanced Management Services, Inc. (AMS), a full service management consultancy servicing an international client base. Phil has utilized his extensive background in management and consulting to lead AMS to its current status as a multi-million dollar enterprise with an international customer base. Phil has led the organization to recognize several strategic breakthroughs such as developing partnerships with distance education providers, software developers and publishers. Through these efforts, AMS has emerged as a leader in consulting, training and assessment services. He has also founded three other businesses which remain under his direction, PTV Equity Management, WIT Group and AMS Aviation. For more information regarding this topic Phil can be contacted at [email protected].