Google



1










What Is Business Analysis? to Business Analysts

What is Business Analysis?

What is business analysis?

In very basic terms, business analysis could be said to be the application of a range of disciplines, to determine business needs and develop solutions to business problems. Of course, in practice this short description becomes entirely inadequate, a far more exhaustive explanation is required to explain exactly what business analysis actually is.


Business Analysis Basics


Business Analysis is a term which refers to the process of firstly identifying the needs of the business and then developing and implementing the solutions to meet them. Business analysis techniques are applied to develop an appropriate plan and then put it in to action. Business Analysts are an important asset to every business, they apply their skills to take the big picture and break it into smaller parts, making it easier to ensure that company resources are being utilized in the most efficient manner.



Business Analysis is Goal Orientated


Business analysis always focuses upon goals, but in a bi-directional fashion. Business analysis can be implemented to both set goals, and to achieve them. These goals will cover strategic business practices encompassing IT, business processes, corporate policies, structure and trading strategies across the entire enterprise.





Business Analysis Is Comprised of
Three Core Elements


The term business analysis is a broad term given to the process of analyzing and influencing three distinctly different aspects of the business, which combined, effect the enterprise at every level, these are:


Business Analysis Techniques


Depending upon the market sector the enterprise sits within, different business analysis techniques will be applied. Different techniques may also be applied at project level. Some of the most common of these techniques are:


These are just a handful of the mainstream techniques which make up the toolset of the modern business analyst. These are very succinct descriptions, each of these techniques is worthy of several pages of description in their own right.


The Three Phases of Business Analysis


Every time that business analysis techniques are applied, there is a natural three phase progression, which can be explained thus:



Why is Business Analysis Important?


Business analysis is important for many reasons, although the main one should be quite apparent; business analysis allows a company to take carefully iterated steps towards achieving greater profitability by working


Every enterprise is the sum of its stock value, working capital, tangible assets, customers, staff and goodwill. By employing modern business analysis techniques, the value of each of these core aspects. Hopefully this has answered the question of what is business analysis.




© 2015 Stellar Force

Business Analyst Community & Resources | Modern Analyst
RSS feeds for Business Analyst Community & Resources | Modern Analyst

Is ETL Still Relevant?
by Limor Wainstein
29 Nov 2017 at 11:23am

The title of this article poses a pertinent question for modern enterprises that increasingly make use of powerful high-end analytic data engines, such as Hadoop clusters and cloud-based data warehouses (see this article by Forbes, which deals with similar questions).

The challenge for enterprises that use analytic engines is one of data movement—what is the best way to get data from operational systems into data warehouses and other data platforms so that it can be queried for reporting and analytics purposes?

ETL (Extract, Transform, Load) is one such method for moving data, and it is one of the oldest data movement methods. However, debate continues as to how relevant ETL still is.

Below you'll find out exactly what ETL entails, some use cases for ETL tools, and whether ETL tools are still relevant in a world where enterprises can leverage powerful modern data platforms to transform data inside those systems to be ready for use with their business-critical applications, instead of requiring a separate transformation engine.


What is ETL?

ETL (Extract, Transform, Load) is a process of moving data from source systems, transforming data in a transformation engine for use with target applications by applying a set of rules to the data (standardizing, aggregations), and finally, loading the transformed data into the target systems, which are usually data warehouses or other data repositories. The end goal of using ETL is to enable businesses to make data-driven business decisions.

Some ETL use cases and examples are:

Pulling data from different transactional systems into ODS (operational data stores) for operational reporting and decision making.  Retrieving data from transactional databases, transforming it for data warehouse use, and loading the transformed data into the data warehouse. Extracting data from XML files, structuring it, and loading to a data mart to serve a particular community of knowledge workers within organizations. What Are ETL Tools Used For?

ETL tools are used to manage the flow of data between source systems and target systems with ETL processes. Organizations can create their own ETL tools using scripts—this approach is suitable for a small number of data sources with similar types of data.

For most use cases, ETL tools created by other companies offer more functionality by implementing data transformations easily and consistently across various data sources, such as XML files and relational databases. ETL tools use transformation engines to sort, join, merge, reformat, and aggregate data.

Enterprises and organizations can avail of either commercially available ETL tools or open-source tools.

Useful ETL Tools

There are several different ETL tools on the market—here are some examples of the most useful ETL tools currently available:

Apatar—this open source ETL tool comes with a practical user interface that can reduce R&D costs. Apatar is written in Java, and organizations can use the tool to easily populate data warehouses and data marts. Scriptella is another open source ETL tool written in Java that can use SQL or any other scripting language to perform data transformations. You can work with multiple data sources ETL file in Scriptella, and the tool integrates with any integrates with any JDBC/ODBC-compliant driver. Stitch is a commercial self-servicing data pipeline that loads data into data warehouses using ETL processes. Stitch requires no API maintenance or scripting, and it can handle both bulk and incremental data updates. Fivetran is a commercially available fully managed data pipeline solution that integrates data from all your cloud services and databases into a single data warehouse using ETL processes. Camel is Apache's open source data integration framework built using Java. Camel has ETL functionality through its available libraries, which can be used to build programs that perform ETL operations. Wait a Minute. Is ETL Still Relevant?

Enterprises are increasingly leveraging cloud-based solutions for their data needs, in particular, for BI and analytics. This 2017 report found that cloud BI adoption increased in respondent companies from 29% to 43% from 2013 to 2016, and that 78 percent of organizations plan to increase their cloud use for BI and data management through 2017.

With powerful modern solutions such as cloud-based data warehouses, it's becoming more common and more practical to take an ELT approach to data movement. ELT (Extract, Load, Transform) is an alternative way of moving data from source systems to centralized data repositories without transforming the data before it's loaded into the target systems.

With ELT, all extracted raw data resides in the data warehouse, where powerful architectures can transform the data as needed to serve business needs. In other words, the transformation is performed when the analytic queries are run.

The major upside to ELT is that there is no waiting—all data is accessible at all times. This is in contrast to the traditional ETL approach to data movement, in which analysts and BI users must wait for the full ETL process to complete before accessing data.

ETL, therefore, is outdated for most use cases. Cloud infrastructure makes data more accessible than ever before, without the need to maintain complex scripts that transform the data for analytic use, as in ETL.

However, ETL still has a place in legacy data warehouses used by companies or organizations that don't plan to transition to the cloud. With the adoption of cloud-based data solutions skyrocketing, it won't be long before ETL completely loses its relevance.

Closing Thoughts All companies or organizations that want to analyse their data to make business decisions are faced with a common challenge—how to move data from source systems, such as transactional databases, to the target systems used for data analysis and BI. ETL provides one way of moving data by pulling it from source systems, shaping it to be ready for use with analytic applications, and finally loading the data to the target systems. There are several open source and commercial ETL tools available that can make the ETL process more functional and practical. However, the transition to cloud-based data solutions makes ETL processes less relevant, because there is no need to transform data before it moves to the warehouse or other analytic repository—cloud infrastructures have the resources to efficiently transform raw data as it is needed. ETL is outdated, but it's still useful for legacy data warehouses used by companies that don't plan to move to the cloud or don't foresee much future data growth.

 


Business Transformation, the importance of understanding your current state.
by EA Learning
31 Oct 2017 at 7:39pm

I recently walked into a large shopping centre on a mission to buy a christening present for a friends son. I was very clear on what I wanted I just needed to find it… I was on my lunch break so I need to get the job done as I had a meeting that I needed to attend back in the office straight after lunch!

I am not a frequent shopper and to be honest I find the crowds and the volume of options at shopping centre’s both distracting and stressful. After walking in from the street the first thing I did was look for a map to show me where I needed to go. I quickly found the map and the section that I needed which was on the 4th floor. There was a big red arrow on the map saying You Are Here. The problem was I wasn’t a 100% sure where You Are Here was, in relation to where I wanted to get to on the 4th floor!

I knew that I had to get to the fourth floor, but was I on the ground floor or the first floor, and where were the escalators and elevators that I needed to find? When I looked at the map again it dawned on me that I wasn’t even sure as which way I was facing. Given that was time constrained my anxiety and I needed to get this job done my anxiety levels started to rise. Should I Just start walking to where I think the escalators and/ or elevators were, or should I take a couple of minutes to orientate myself?

I did a quick environmental scan and identified a couple of the nearby shops which allowed me to determine which floor I was on. I then found the entrance that I had come in from on the map which allowed me to orientate myself. The easiest option was to take the escalator, as they were closest. I had a clear map in my head of where I was, where I needed to go, how I was going to get there and what I was going to do when I arrived. My anxiety levels immediately decreased as I felt confident that I would be able to get the job done and be back in the office before my next meeting.

The key piece of information that facilitated the whole thing was I knew where I was starting from. To use Business Architecture parlance, I understood my current state!

Whenever you are setting off on a journey be it a trip to the shops, an overseas holiday, a journey of personal discovery or a process to Transform an organisation one of the key determinants of success is knowing where you are starting from. While it sounds simple in practice it is one of the most difficult tasks in the Business Transformation process.

When you speak with stakeholders within an organisation undergoing Transformation about the current organisational state you will often get as many views as there are business functions within the organisation. Often to the point that there is often not even agreement on what Business Model the organisation utilises or even what business they are in.

The interesting paradigm is that while most people can’t agree on where they are, there is often clear agreement on where they want to be! In most cases, the board has set a clear strategy which has been codified into the annual business plan and presented to management. The goals and objectives detailed in the business plan are aspirational, without a detailed understanding by the executive of what the organisations' current capabilities are, and it is the role of management to figure out how to deliver them.

Management identifies initiatives required to achieve the business plan, goals and objectives and allocates budgets. The initiatives are usually developed based on functional responsibilities and often in isolation to the rest of the business. Management then starts executing on the Transformation initiatives, and this where the wheels often fall off the Transformation process.

The main reason for this is that there is no clear plan or blueprint to define the organisations' current state to connect the business plan to the Programme of Transformation initiatives. There is no Business Architecture to clearly direct people on their journey, and in many cases, people aren’t 100% sure what specifically needs to change. They just know that there are goals set out for them in the business plan and they need to meet them.

What ensues is a lot of activity and consumption of resources without many tangible outcomes.

In most cases, Transformation teams are clear on the Target Operating Model (TOM) that they want to achieve but they are not able to clearly define their current operating model and consequently, do not know what the most efficient and effective way is to achieve the TOM. Every year in Australia millions of dollars are spent on Business Transformation initiatives that do not deliver any demonstrable business improvement and one of the fundamental reasons for this is that organisations set off on their transformation journeys without a sufficient understanding of where they currently are.

A quick postscript to my shopping journey. I made it to the 4th floor without too many distractions. When I got there I couldn’t find what I was looking for, but luckily as I was in the right area for Christening presents I found an alternative that was better and returned to the office in time for my next meeting. If only all journeys were so simple.

If you are interested in our Business Transformation training, please contact us for more information on how we can assist. Click here to view our course range and to send through an enquire or email info@ealearning.com

Written by Scott Comte, General Manager EA Learning 


UX Canvas
by BusinessAnalysisHub
26 Oct 2017 at 1:25pm

Have you woken up in the middle of night thinking how am I going to steer my team, give them the direction that they need but at the same time not constraint in what they want to build/deliver. I recently went through one of these night- I have joined an interesting project where we have very tight timescale to deliver a tech product to operational staff. When, I say tight we are talking about the end product had to be delivered within 100 days.

We had recently finished the discovery stage of the project, this had been very frantic and time pressured led- we only had three weeks to do our discovery. This naturally resulted in the team not having the opportunity to speak and consolidate their findings with each other.

As, the lead business analyst on the project, it was my role on the project to make sure that we had the best picture of what the current ‘As is’ situation was like on the ground. It is also my role to make sure that we have got access to the policy and legal requirements that we had to work within.

It was when we were heading rapidly towards the end of Discovery that I came to the realization that we had access to lots of information and ideas within the team. We needed some place where we could come together to discuss our findings and learning with each other.

I learnt about Lean UX Canvas from this Jeff Gothelf blog that I happened to stumble across. I have always been a big fan of Jeff Gothelf especially his book ‘Sense and Respond’, so naturally I was curious about this canvas.

I have used product canvas, business model canvas and opportunity canvas with the team but this was first time I had come across UX lean canvas. I was drawn to the canvas, as it had everything that we needed as the team — user benefits/ riskiest assumptions

For me this was a perfect tool, as it allowed everyone to contribute their findings into this one artefact, that we as the team could reference back to. Once, I decided I was going with this tool, I introduced it to the team, whom seemed to be onboard with trying it out.

The best way to complete the canvas for me was to get the team together in the collaboration space and start having the conversation around the different components within the canvas. We decided the core area we needed to agree first was ‘what was the business problem that we are trying to solve’.

Once, we agreed then we could then tackle what ‘Solution ideas’ that our products need to have. I must admit this is one that caused us the most discussion in the team- as the user researcher thought the solution should cover certain things while the service manager was not necessarily in agreement. However, by having these discussions we were able to expose areas that we still needed information on, or where we had gaps in knowledge in the team.

We then, went around the canvas completing the different blocks within it. It took the team about a day to complete the canvas — which I think is ideal time period to do something like this.

I would definitely recommend utilizing this tool with your team, it is a great way to bring all the professions together to get them discuss their findings. It, is also a great tool to generate conversation around the product that you are developing as a team.

My other tip for doing a Lean UX Canvas is that it does not have to be perfect, don’t spend time trying to make it look pretty- we completed ours on brown paper that we took a photo of. This tool is not about a prefect artefact but instead it’s about making sure that as the team you can all agree what is the problem you are trying to solve, the hypothesis that you want to test and the riskiest assumption that you want to test first.



When is Security not a Non Functional Requirement?
by Peter
22 Aug 2017 at 1:12pm

If you are building a reusable Security Product tool to specifically address Security Technical Implementation Guide (STIG)  Findings, should the requirements be considered Non Functional Requirements or Functional Requirements?

For example if there are a number of STIGs such as:

The minimum password length shall be 15 characters The maximum password length shall be 30 characters The password shall contain at least one of each of the following types of characters Numeric Character Uppercase Alphabetic Character Lowercase Alphabetic Character Special Character (!,@,#, etc.) The password shall be changed a maximum of every 60 days

 should I add them to the Functional or Non Functional section of my Requirements Document.

Add your answers and thoughts in comments below:


5 Business Problems You Can Solve Using SQL Temporal Tables
by Bert Wagner
11 Jul 2017 at 6:08am

It’s 4:30 pm on Friday and Mr. Manager comes along to tell you that he needs you to run some important ad-hoc analysis for him.

Previously this meant having to stay late at the office, writing cumbersome queries to extract business information from transactional data.

Lucky for you, you’ve recently started using Temporal Tables in SQL Server ensuring that you’ll be able to answer your boss’s questions and still make it to happy hour for $3 margaritas.

Sound like a plan? Keep reading below!

The Data

For these demos, we’ll be using my imaginary car rental business data. It consists of our temporal table dbo.CarInventory and our history table dbo.CarInventoryHistory:

I’ve upgraded my business — we now have FOUR Chevy Malibus available for you to rent Business Problem #1 — “Get me current inventory!”

To get our current inventory of rental cars, all we have to do is query the temporal table:

SELECT * FROM dbo.CarInventory

That’s it.

I know this query seems lame — it’s just a SELECT FROM statement. There are no FOR SYSTEM TIME clauses, WHERE statements, and no other interesting T-SQL features.

But that’s the point! Have you ever had to get the “current” rows out of a table that is keeping track of all transactions? I’m sure it involved some GROUP BY statements, some window functions, and more than a few cups of coffee.

Temporal tables automatically manage your transaction history, providing the most current records in one table (dbo.CarInventory) and all of the historical transactions in another (dbo.CarInventoryHistory). No need for complicated queries.

Business Problem #2 — “How many miles on average do our customers drive each of our cars?”

In this example, we use FOR SYSTEM_TIME ALL and a plain old GROUP BY to get the data we need:

SELECT
CarId, AVG(Mileage) AS AverageMileage
FROM
dbo.CarInventory FOR SYSTEM_TIME ALL
WHERE
InLot = 1 -- The car has been successfully returned to our lot
AND SysStartTime > '2017-05-13 08:00:00.0000000' -- Ignore our initial car purchase
GROUP BY
CarId Some cars get driven a lot more. Causation or correlation?

FOR SYSTEM_TIME ALL returns all rows from both the temporal and history table. It’s equivalent to:

SELECT * FROM dbo.CarInventory
UNION ALL
SELECT * FROM dbo.CarInventoryHistory

Once again, there isn’t anything too fancy going on here — but that’s the point. With temporal tables, your data is organized to make analysis easier.

Business Problem #3 — “How many cars do we rent out week over week?”

Here at Wagner Car Rentals we want to figure out how often our cars are being rented and see how those numbers change from week to week.

SELECT
CurrentWeek.CarId,
CurrentWeek.RentalCount AS CurrentRentalCount,
PreviousWeek.RentalCount AS PreviousRentalCount
FROM
(
SELECT
CarId,
COUNT(*) AS RentalCount
FROM
dbo.CarInventory FOR SYSTEM_TIME FROM '2017-06-05' TO '2017-06-12'
WHERE
InLot = 0 -- Car is out with the customer
GROUP BY
CarId
) CurrentWeek
FULL JOIN
(
SELECT
CarId,
COUNT(*) AS RentalCount
FROM
dbo.CarInventory FOR SYSTEM_TIME FROM '2017-05-29' TO '2017-06-05'
WHERE
InLot = 0 -- Car is out with the customer
GROUP BY
CarId
) PreviousWeek
ON CurrentWeek.CarId = PreviousWeek.CarId

In this query, we are using FOR SYSTEM_TIME FOR/TO on our temporal table to specify what data we want in our “CurrentWeek” and “PreviousWeek” subqueries.

FOR/TO returns any records that were active during the specified range(BETWEEN/AND does the same thing, but its upper bound datetime2 value is inclusive instead of exclusive).

Business Problem #4 — “What color cars are rented most often?”

We’re thinking of expanding our fleet of rental vehicles and want to purchase cars in the most popular colors so we can keep customers happy (and get more of their business!). How can we tell which color cars get rented most often?

SELECT
CarId,
Color,
COUNT(*)/2 AS RentalCount -- Divide by 2 because transactions are double counted (rental and return dates)
FROM
dbo.CarInventory FOR SYSTEM_TIME CONTAINED IN ('2017-05-15','2017-06-15')
GROUP BY
CarId,
Color

Here we use CONTAINED IN because we want to get precise counts of how many cars were rented and returned in a specific date range (if a car wasn’t returned — stolen, wrecked and totaled, etc… — we don’t want to purchase more of those colors in the future).

Business Problem #5 — “Jerry broke it. FIX IT!”

The computer systems that we use at Wagner Car Rentals are a little…dated.

Instead of scanning a bar code to return a car back into our system, our employees need to manually type in the car details. The problem here is that some employees (like Jerry) can’t type, and often makes typos:

SELECT * FROM dbo.CarInventory FOR SYSTEM_TIME ALL WHERE CarId = 4

Having inconsistent data makes our reporting much more difficult, but fortunately since we have our temporal table tracking row-level history, we can easily correct Jerry’s typos by pulling the correct values from a previous record:

;WITH InventoryHistory
AS
(
SELECT ROW_NUMBER () OVER (PARTITION BY CarId ORDER BY SysStartTime DESC) AS RN, *
FROM dbo.CarInventory FOR SYSTEM_TIME ALL WHERE CarId = 4
)
--SELECT * FROM InventoryHistory
/*Update current row by using N-th row version from history (default is 1 - i.e. last version)*/
UPDATE dbo.CarInventory
SET Color = h.Color
FROM
dbo.CarInventory i
INNER JOIN InventoryHistory h
ON i.CarId = h.CarId
AND RN = 2 Typos fixed!

Although we could have fixed this issue without using a temporal table, it shows how having all of the row-level transaction history makes it possible to repair incorrect data in more difficult scenarios. For even hairier situations, you can even roll-back your temporal table data.

Conclusion

Temporal tables are easy to setup and make writing analytical queries a cinch.

Hopefully writing queries against temporal tables will prevent you from having to stay late in the office the next time your manager asks you to run some ad-hoc analysis.

-----

Bert Wagner

https://blog.bertwagner.com


A New Metaphor for Business Analysis
by Ronak Sanghavi
25 Jun 2017 at 12:29pm
Current State

For many years now, the most commonly used metaphor on Business Analysis has been the “Bridge”. However, in recent past, some in the BA community have started revisiting the metaphor resulting in a debate on how relevant it is. Of course, the value business analysis can provide for an organization does not depend on how it is described. So does that mean we should ignore this debate? I don’t think so. A metaphor is a powerful tool to develop useful mental models, and efficiently create possibilities for value-creation.

My take on this debate is that both sides are right. This is so, because the state of business analysis is not uniformly mature across countries and work cultures. For instance, BAs in North America are more likely to find the “Bridge” metaphor limiting/restrictive because of how the role has matured in the past decades. On the other side, for most BAs in emerging economies the “Bridge” metaphor still provides aspirational value.

So, what is behind my ambivalence? Most common interpretation of the metaphor is that it connects business and IT stakeholders. My take is that it is a bridge between the problem domain (current state) and the solution domain (future state). This take on the “Bridge” metaphor is not limiting, because it includes all levels of business analysis maturity - from strategy analysis to solution evaluation, and everything in between.

A New Metaphor

Not that there is anything wrong with a debate, but it is time for a new metaphor. I would like to share with the BA community a metaphor which has shaped my business analysis journey, especially in the past 5 years since I co-founded a business analysis startup. I look at business analysis as a “GPS” to move from the current state to the desired state. In other words, it guides stakeholders to achieve project success and organization goals. This metaphor is more inclusive (represents all flavors of BA role) and accurate (represents full potential of the discipline).

Let us look at the elements (features) of the conventional GPS system, which make it so useful; and how business analysis aligns with them.


#

GPS Feature

How Business Analysis aligns with GPS Feature in Projects

0

MAP – a useful representation of the landscape

· Build a representation of the business and IT landscape through research and analysis of industry; market forces, including competition; organization; operations; and current IT systems

1

CURRENT LOCATION – ability to determine current location in the context of the MAP

· Provide appropriate context for a project by customizing and sharing with stakeholders the relevant business and IT landscape

· Define current state of the problem domain, and frame the problem statement

2

DESTINATION – assistance to select destination, e.g. a highly rated Point of Interest

· Help organizations prioritize IT investments through business cases

· Facilitate definition of the desired state through solution scope and requirements specifications

3

NAVIGATION – real-time navigation to help reach destination most efficiently

· Facilitate selection of the best solution to meet requirements

· Facilitate shared understanding of requirements through requirements transition, continuous communication, traceability and change management

· Identify, engage, collaborate and coordinate with stakeholders; and support them to achieve desired solution

 

Any single feature, from the list above, is useful by itself. The “GPS” metaphor on business analysis is inclusive and aspirational enough regardless of the maturity of the BA role in a country, work culture, organization, or even an individual project. Furthermore, by symbolizing the positive global impact GPS has had on humanity, this metaphor helps us quickly and robustly communicate the power and value of the business analysis discipline.

My Experiments with this Metaphor

The “GPS” metaphor is not just a concept, which I made up for the purpose of writing this article. This mental model has fueled my passion, and shaped how I have approached business analysis in the latter part of my career. In fact, all service and solution offerings of my company are built on this mental model. I have received favorable and instant acceptance of this metaphor every time I have pitched my company’s solution portfolio to potential clients. I have also received positive feedback in training and coaching interactions from individuals when I have used this metaphor to provide more clarity about business analysis.

Your turn

I would love to hear your views on this. I hope that your active and constructive participation in this dialogue will not only help me crystallize my thoughts on this topic, but also give the BA community a new metaphor to actuate and communicate the potential of our profession.



What is Pega Process Managment?
by SarikaA
29 May 2017 at 3:50am

Pega systems(Software Company) is the leading provider of business process management (BPM) and customer relationship management (CRM) software solutions. Pega systems motto is “Build For Change” and their goal is to “eliminate software coding” and “automate manual work”.

Pega systems has been at the forefront of rules-based business automation systems since the early 1980s, a natural outgrowth of our founder’s pioneering work in computerized chess play. In recent years, as more and more businesses have concluded that business process management suites are a “must-have” technology, our BPM business has grown at twice the rate of the overall BPM market. At the same time, major analysts like Forrester and Gartner have consistently rated Pega systems as the leader in the dynamic BPM sector.

Pegasystems knows that what it all comes down to is delivering real-world business benefits, efficiently and quickly:

More so than any other process management suite, Pega BPM puts business users in control of process design and creation, while automating most of the code development and minimizing reliance on technologists.

Pega BPM patented inheritance technology enables a multi-layered process model in which a base of enterprise-wide rules and procedures are dynamically merged with an overlay of context-specific refinements suitable to particular regions, product lines, channels, or customers. This model enables you to capture in your BPM services a real-world reflecting mix of the universal and the particular.

To speed your time-to-benefits, Pega BPM offers a full range of industry-specific solution frameworks, based on best practices in financial services, insurance, health care, telecommunications, government, and others. For business process outsourcers, we also offer tailored BPO software and BPO solutions.

The perfect platform for enterprise-scale business performance management or business process integration initiatives as well as for more narrowly targeted pilot programs, the Pega business process management suite empowers business users, accommodates real-world variety, and pays rapid dividends.

End-to-End Business Process Management Services

Pegasystems delivers expert business process management services to support all phases and facets of your BPM project:

-Design review — Pegasystems’ business process management services team can help you get your BPM project off on the right foot with a thorough review of your application design. Working side-by-side with your project team and leveraging best-practice design principles, Pega BPM services staff will provide valuable feedback on both your design and your design process.

-Usability review — No matter how well-designed an application is internally, and no matter how powerful the underlying business process management system, the application won’t live up to its potential if your user interfaces are not meeting the needs of end users. The Pega business process management services team will review your UIs from the user perspective and help you identify ways to improve the user experience and increase user productivity.

-Transition readiness — Before you launch, Pega business process management services professionals will help you test your application, tune it, and prepare it for deployment. We’ll also work with you to assess your organization’s readiness to utilize the application.

-Performance check-up — Once your BPM application has been up and running for six months to a year, Pega professional services can evaluate your application’s performance to see whether you’re getting your maximum possible return. Detailed analysis and feedback from Pega business process management services -personnel can help you to fine tune your application and to optimize future applications as well.

-BPM methodology coaching — Pegasystems veteran BPM experts can coach your team on all the nuances of implementing an iterative and agile BPM methodology that best leverages the robust capabilities of your Pega BPM platform.

-Centers of excellence creation — Many leading companies are creating BPM-focused Centers of Excellence to drive BPM implementations across the enterprise. Pega professional services can help you with all aspects of launching a BPM Center of Excellence, including strategy development, infrastructure creation, and building of a BPM knowledge base.


Identifying requirements, the right way
by Surbhi Mahnot
10 Apr 2017 at 1:10am

Requirements define the needs of the project to provide best of its utility and benefits. If they aren’t clear or analysis is not done properly, it might lead to failure of the project no matter how good the concept and design is.

Just as a system is composed of various functionalities, requirements too are identified in various forms. This categorization of requirements makes analysis process much simpler and clear for all the involved stakeholders. As per BABOK, the requirements are primarily categorized as:

Business Requirements Stakeholder Requirements Solution Requirements - Functional and Non-Functional Requirements Transition Requirements

With so many requirements to identify it is very easy to get confused with how to identify these requirements?

A simple approach is to visualize the complete process and start step by step

To do that, let’s look at cooking for an example:

When you plan to cook a meal, you first take in account for whom you are cooking. Is it for yourself or for your family or the kids? These define your Business Requirements. Once you decide this, you figured that you will sip wine along with the food and the kids won’t eat spicy food (stakeholder’s requirements). Next, you get all your ingredients for the meal (functional requirements) and you might also take in consideration the time you require to prepare the meal and preparation required for serving the food (Non-functional requirements). Finally, you prepare a delicious penne arrabbiata pasta topped with oregano and basil leaves (technical requirements).

Now, let’s understand each of these requirements with a technical example, Implement Log-in functionality.

Business Requirements: These are high-level business objectives or goals or needs of an organization. The business requirements document (BRD) usually includes what features would be there in the product, what market the business will expand or enter, risk assessment, success measures from the business point of view, etc.

Example: There shall be a Login screen through which Users will log into the system.

Tip to identify:

Words or phrases that describes what, such as “we need to be able to”, “we need to solve this” and “we need a way to”.

Stakeholder (User) Requirements: These are what every stakeholder needs/expects from the solution and how they will interact with the solution. Often the stakeholders can explain the entire system in detail from their perspective only. Each stakeholder sees the problem from unique perspective. Therefore, you must understand all the needs to understand the complete system. All these requirements must be analyzed in such a manner that it doesn’t conflict with each other.

Example:

As a customer, the user shall be redirected to Dashboard on successful login. (Stakeholder - Customer).

As an admin, the user shall be redirected to the Administrator’s landing page on successful login. (Stakeholder -  Administrator).

Tip to identify:

Similar to business requirements, but from user's perspective. Words or phrases that describes what, such as “we need to be able to”, “we need to solve this” and “we need a way to”.

Solution Requirements: These specify the detailed conditions and the capabilities that the solution must have to meet the business and stakeholder requirements. Software Requirements Specification (SRS) is created to capture both functional and non-functional requirements. These are categorized into two:

a.      Functional Requirements: These define specific behaviors, responses, information, rules for the solution primarily addressing the following:

The features the system will support (Functional capabilities) Data validation rules and how they will be managed (Business Rules) Interaction between different stakeholders (users) within the system (Use cases)

These include a complete description of ‘how’ the system will be built.

Example:

Registered users shall be able to login with valid username and password On successful login, user shall be redirected to a landing page in the system On failure, for not registered username prompt "Username not registered" message and for invalid credentials prompt "Invalid credentials" New users shall be able to register with the system by clicking on the "Sign-Up" link Users shall be able to recover password by clicking on "Forgot Password" link

b.     Non-functional Requirements (Quality-of-service): These define the environment in which the solution will operate. The qualities a solution must have or constraints within which it must operate smoothly. They define standards for Usability, Reliability, Security, Accessibility, Performance, Information Architecture, Portability, Extensibility, Internationalization, Integrity or anything that would help the success of the system in real-world.

Example:

Performance: On successful login, user shall be redirected to the landing page within 10 seconds (max) Maintainability: Proper logs stating the operation result with timestamp shall be added on every login/signup/forgot password click Platform: The login functionality shall behave same on different platforms (Windows/Linux)

Tip to identify:

To easily identify between these, functional requirements can be considered as “verbs” and non-functional requirements as “adjectives” on these “verbs”.

Transition (Implementation) Requirements: These define conditions or capabilities only required to enable transition of the solution from development to real-word business use. It describes what must be done with the process, technology, education, training, enhancements before getting from the as-is into the to-be.

Example: Not valid in this example but for explanatory purpose: The login system shall behave same once "Single Sign-On" functionality is implemented

Tip to identify:

Look for temporary requirements such as “migrate from old system to new system”.

There are many other types of requirements that are used across diverse types of systems based on the scope such as:

Technical Requirements: Once the solution requirements are clear, the best way to start with the development frequently involves technology. It is a way to communicate between analyst and engineers (programmers, architects, designers) and is often written by the technical engineers. These requirements specify design and architecture for the solution components to be developed and implemented. They define how the solution will be programmed, store data and display data.

Example:

Browser support: Current and recent versions of Firefox, Edge, Chrome, Internet Explorer, Safari, Opera Requires browser to have JavaScript enabled

Tip to identify:

Technical jargon's are used such as “password encryption algorithm” and “database schema” etc.

User Interface Requirements: These define the user interface design for the functionalities (derived from solution requirements). The placement of user input controls, buttons, links etc. on screen to allow the working of the functionality. Generally represented with wireframes.

Example:

Textboxes for username and password shall be placed below the respective labels for Username and Password Login and Cancel buttons shall be present in center of the screen Sign-Up link shall be present below the Login button Forgot password link shall be present above the Login button

Requirement analysis is all about understanding, identifying and categorizing these requirements. With categorized requirements, it becomes much simpler for the team to understand and follow the system details.

#requirements


Challenges in Implementation
by Sanjay Yadav
20 Mar 2017 at 7:34am
 Challenges in Implementation:
 

 

I’m a strong believer of putting finishing touch to any initiative. Project Initiation is always tough and complex and need lots of research but if BA is unable to give the finishing touch then he is not done yet. So, I thought to put few of my views, challenges and observations during Implementation phase that I have faced. BABOK does a great job in explaining the Strategy Analysis and Solution Evaluation however real time challenges are most of time unspoken. As a Product based Business Analyst I often face few challenges which are altogether different than the last one.

 Stakeholder involvement and Governance: This is one of the challenging and critical step to find out the exact governance of stakeholders. Each stakeholder interest towards the product implementation do impact the final stage of the product. Lack of interest do hamper the product implementation. So if any stakeholder has less interest so its critical to know the reasons. Sometimes its better too to know why if any stakeholder shows more than needed interest. Maintaining correct and verified Project Charter does help in this.

 Over Expectation: Customers are always demanding and they should be as they are the one who are paying for all these, however as a Business Analyst you must be very smart to distinguish the expectation and over expectation of client because over expectation often makes your system more complex to use by the end-user and customer which ends with spending more bucks and gaining less.

 Deadline and Release Planning: As a business analyst make sure that circumstances don’t control you and your team, and you deliver your project successfully even if you don’t meet the original deadline. The art of prioritizing the solution requirement helps you to pass through. You should keep some time in buffer so that you have availability of resources to fix the unwanted issues or the deadlock condition in approval or implementation.

 The Acceptance: Most of the time I have found more involvement of people in acceptance compared to when you do the brainstorming or focus group. Sometimes customer say that they aren’t looking for this altogether. So, providing a view of your product before acceptance saves you. Do not ever try to give more than requirement (without information), customer will treat it as a bug because they haven’t requested it. Though sometimes over-explanation saves.

 Training: Sometimes it happens that everything is as per the client request and you are at a better stage to close the project but you end with hearing that there is no such benefit by the new implementation. I have observed that sometimes the user is not aware of the new feature or do not know how to use the new feature at all. So, Training to right people is very important. Sometimes you should move desk by desk to see if customer the using it fully.

 Getting feedback: Learning from your mistake is very important however knowing what went perfect is important too. Feedback from customers is very important to learn and grow as a business Analyst.

There are number of other challenges that do a Business Analyst phase. I would love to hear. 

 


Defining Requirements
by Surbhi Mahnot
16 Mar 2017 at 7:47am

All professionals talk about identifying business needs, identifying requirements to create tools so that they can help businesses take better decisions. In your career as an IT professional, I am sure at some point you must have heard terms such as “Requirements”, “Business Requirements”, “Software Requirements”, “Project Requirements”, “Technical Requirements” and the list goes on.

So, what are these requirements?

“Ours is a world where people don’t know what they want and are willing to go through hell to get it.” — Don Marquis

Well, to most of the people, this appears to be a simple question. But, this is the most complex question to answer (for the professional responsible to gather requirements, primarily a Business Analyst) as it takes forever to ask and understand “What are the requirements”.

Different people have different ideas of requirements. For a product owner, requirement is as simple as the ability to use/sell the product that helps with the business and revenues. For a project manager working on that solution, requirements are to get the solution developed with best quality that meets all the expectations of the client and minimize resource allocation to bring most benefits to the company. For a team lead, requirements are to identify the technical challenges, build a maintainable architecture and get the solution developed smoothly. For a developer, requirements are to develop the assigned feature or make changes in the software as requested.

Requirements, at first glance are really needs (end objective), wants, suggestions or ideas. Derived from those needs, we set an objective and take a decision about what things should be done or not to be done to achieve that objective.

Requirements are a set of prioritized needs from all the involved stakeholders that form the base for the functionalities or features to be included as a part of the solution.

Per BABOK guide, official definition of requirement is:

1. “A condition or capability needed by a stakeholder to solve a problem or achieve an objective.” In simpler words, a decision-making process to derive requirements from needs.

2. “A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specification or other formally imposed documents.”It is a step where business requirements are drafted as solutions requirements to get started with developing the solution.

3. “A documented representation of a condition or capability as in 1 or 2.” The documentation is itself a requirement as it helps all the stakeholders and consumers in understanding the requirements for the solution.

Where do these requirements come from?

All the requirements arise from a need. We need to understand those Business Needs or the Business Problem Statement. Unless there is a problem, we can’t think of providing a solution. A lot of analysis and research is carried on before requirement analysis to understand the problem. These involve feasibility study, knowing business terms and concepts, cost/benefit analysis, business strategy etc.

A Business Analyst (BA) starts with a broad and general description of what needs to be done and then starts working with key stakeholders to define the project scope (inclusions and exclusions), high-level business requirements, solution requirements, technical requirements and transition requirements primarily.

Talking about stakeholders, it’s important to know about who they are and how critical is their involvement in the project.

Who are stakeholders?

A stakeholder is a generic term for a person or group of people who are involved with the project (directly or indirectly) and have a say in decision making process of the project. They can be:

Executive Sponsor — Mostly concerned about funding of the project and high-level information Product Manager — Make important decisions for the project and review & approve requirements Project Manager — Prepares project plan, resource allocation plan, manages the execution of the project and works very closely with the BA (Business Analyst Subject Matter Experts — Assists in defining project scope, works with the BA to define business rules, processes and user interface

There is a whole set of other roles such as Technical Personnel, Technical Writers, Quality Assurance Personnel, Database Administrators and others who can be important stakeholders in a project, depending upon the needs.

How stakeholders help with requirements?

Since each stakeholder plays a different role in the project, they have different requirements too. Sometimes, what emerges as the biggest challenge for a BA is to extract useful information from all these stakeholders that matches the preferences best with the client’s business. This is because each of them view the project from their own perspective!

To create best requirements for a project, identifying responsible stakeholders is important. There are many techniques available such as RACI matrix. Not all stakeholders are important for every project. It is primary task to identify the right stakeholders and their say in the decisions to keep things smooth in long run. (When all speak, it becomes real hard to reach to any conclusion).

How are requirements identified? “The most difficult part of requirements gathering is not the act of recording what the user wants, it is the exploratory development activity of helping users figure out what they want.” — Steve McConnell

The process to identify requirements from the needs or conditions is termed as Requirements Analysis. A detailed analysis is critical to solution’s success or failure. It involves the tasks as analyzing, documenting, defining, validating, documenting and managing the changing requirements. There are different standards set in different organizations for the requirement analysis though the primary steps could be identified as:

Identify stakeholders Requirements Elicitation — capture stakeholder requirements through various techniques such as interviews, questionnaire, joint group discussions, prototypes or use cases Identify requirement categories — categorize all the gathered requirements into functional, non-functional, business, technical or transitional requirements Analyze requirements — analyze the requirements whether they are clear, complete, unambiguous, consistent and testable Requirements documentation — requirements are documented in various forms such as Business Requirements Document (BRD) to describe business requirements, Software Requirements Specification (SRS) to describe functional and non-functional requirements, Use cases and User stories (in agile context)

These recorded requirements documents are then collaborated upon to receive feedback from all involved stakeholders. Once the requirements match the needs for the project, it is important to take sign-off to freeze the scope of work and avoid frequent scope creeps at later stages.

Why are requirements important?

Per new research,

Success in 68% of technology projects is “improbable.” Poor requirements analysis causes many of these failures, meaning projects are doomed right from the start Companies pay a premium of as much as 60% on time and budget when they use poor requirements practices on their project Over 41% of the IT development budget for software, staff and external professional services will be consumed by poor requirements at the average company using average analysts versus the optimal organization

Requirements serve as the basis for the project plan and if there are inadequate or incorrect requirements, entire project will suffer at the end.

They are used as inputs into the design stages of product development They are important input for verification process for the product developed They represent what functionalities are necessary for the product Excellent requirements leave no room for interpretation, confusion or omission of critical details and is easily understandable by everyone involved in the project.

Next time when you start with your project, make sure you have all your #requirements…clear and loud!

Stay tuned for more with requirement types, characteristics and more coming up!

This article was originally published by me on LinkedIn


Experience Age - a new era
by Edward
14 Dec 2016 at 12:03pm

A few weeks ago, one of my colleagues surprised me with a statement he made during our team meeting that the information technology age is coming to an end. I looked at him in complete disbelief. How can the advances that have brought so much convenience to our lives be said to be coming to an end.  I thought he must be mistaken, and just like a student who has just been given a topic for an assignment, my curious nature of always wanting to know kicked in and I set out on my little research – not to pass this time, but to prove him wrong.  I asked myself how can we live without information technology, and how can life be better without information technology, which has brought with it globalization – a concept that shrunk the world into a small village.

However, after reading a few articles on this topic, I realized that just like there were other ages before – for instance, during the 17th century human beings lived off the land, and were mainly agrarian. During the 18th century – the Industrial revolution happened – ushering in a new era in the history of mankind – the Industrial age, and continued to evolve through to the 19th century. That too subsided in the 20th century and gave way to the new kid on the block – technology, which revolutionized communication by introducing telephone, radio and television. And we have come a long way since then.

Needless to say, the advances that have been made in the technology space have been in leaps and bounds since the invention of the telephone line, and created what has come to be known as the ‘information technology’ or ‘information economy’ age. It is the world as we currently know it, and as we currently expect to operate.   However, the earth has never stopped moving….it continuously orbits the sun 365 days a year.  This means that, as much as we have felt comfortable with what we have come to know - the ‘information economy’ age – this period was also never here to stay either. At some stage, just like the earth is consistently in motion – this age would have to come to pass, and make way for a new order of things.

At the centre of the information technology age is the focus of acquiring, storing and processing data to meaningful information and insights to better organisations’ economic progress.  And as we in the first quarter of the 21st century, the non-stopping advances in technology are preparing us for a new era – the experience age. It is reported that by 2025, which is a mere 7 years away, the virtual reality experience will be almost close to the new reality – such that conscious efforts will have to be made to make people to be able distinguish between the real ‘reality’ and the ‘virtual reality’.  This age will bring with it a complete paradigm shift – from how data is collected, stored and processed to become meaning and useful information in the form of business intelligence to how consumers will experience products and services offered by organizations.

The significance of data collection and/or data mining to gain customer insights will no longer be of primary focus. The experience age will necessitate the creation of virtual reality for the consumers to experience a product and/or a service even without buying it. For example, they will feel like they are ‘physically’ at the stadium watching a soccer or rugby match, while sitting in the comfort of their homes.

 

The experience age will extend the use of technology even further. It will allow for the use of technology to enable the consumers to experience a product or a service in that moment as if it were real or as if they were already consuming it, even though they were still trying it out. Some of this might sound far-fetched and just a fantasy. However, who would have thought that the demand for voice calls on mobile devices would be replaced by the demand for data services like WhatsApp – a move that has just happened over the past 5 – 10 years? And to push the envelope even further, the demand for data services for chatting and sharing of pictures or videos will soon be replaced by demand for data services for video calls – something that Facebook has realized and now introduced video calling on WhatsApp. Consumers will demand the experience of seeing each other as they are talking to each other. Yes, this is already happened in some parts of the world, but not at the ubiquitous level at the moment.  This is the experience age shaping up right before our eyes.

The experience age will also be of great benefit to the services market. At the moment, consumers can only experience the quality of the service offered by a hotel by physically staying at the hotel. However, with the advances in the experience age, the consumer will be able to take advantage of the virtual reality and experience the stay at the hotel before actually staying at a particular hotel. At the moment, all that thought and decision making process of which hotel to choose is driven by data – either personal or impersonal, i.e. either through word of mouth from friends who have stayed over at that hotel, or through what the hotel publishes about itself on websites, brochures and other sources of information. And all of these touch points may prove, as some of you may agree with me, very deceiving and lead to a disappointing experience.

In the product market space, gamification will probably become one of the dominant form of introducing the experience age to the consumers. In this way, technology will be used to create games for customers to experience the product they are interested in even before buying it – as part of playing the game – as opposed to reading about what the product can do or see the TV ads about what a product does. 

We cannot speak about the experience age and leave out the new buzz word, the IoT – the internet of things. This concept simply means that every device with a power switch can be hooked on to the internet – the connectivity to the internet will not only be exclusive to devices such as laptops, computers, mobile telephones.  These devices include cars, televisions, fridges etc. The ability of these devices to connect to the internet will also change how we ‘experience’ the world we live in.

Cars will be able to communicate with each other, with the traffic lights, with mobile devices of the people you are having a meeting with to advise them that you are running late, to identify roads congested with traffic due to accidents or traffic lights that are out, and to decide alternative routes. Fridges will be able to contact your local supplier to order milk or whatever it is that you will be running short of. We currently see the advances made by smart TV’s which are already able to connect to the internet. Thus the IoT will be another form through which the ‘experience age’ is rendered to us by technology.

Therefore, the paradigm shift I referred to earlier on means that organizations will have to change their strategies, as the focus will no longer be on relying on big data to run analytics, but rather on using technology to provide real time experience to acquire and retain customers.  The experience age calls for a different mindset, bearing in mind that consumers are also changing. We are talking millennials now, and no longer the X’ers and the Y’ers – and they have a different view of the world – which is proving to be a challenge to both their employers and companies offering services or products to them. And I believe that this is food for thought for us in the information technology space.  In order to adapt, companies have to gear themselves and their mindsets towards IoT, robotics and experience age to remain relevant and up to date with the new era.
10 TIPS FOR A BA TO WORK EFFECTIVELY WITH A PROJECT MANAGER
by Chileshe Mulenga CBAP PMP
7 Nov 2016 at 11:44am
EXECUTIVE SUMMARY

The Business Analyst and Project Manager are team players on a project. As is common the Business Analyst and Project Manager sometimes have conflicting approaches during a project.

Having frequently taken up dual roles of a project manager and Business analyst during the course of my career, I have gained some insight on the dos and don’ts for a business analyst to work effectively with a Project Manager

The following are the 10 recommended Tips:

TIP 1 – Collaborative Stakeholder Analysis

Key to your success as a Business Analyst on any project is identifying your key stakeholders and having a good understanding of their interests and levels of influence. From my experience this is a task best done in collaboration with your Project Manager to ensure you speak the same language when it comes to managing your stakeholders. Imagine a situation where you haven’t captured the requirements a highly influential stakeholder already identified by your Project Manager. This could in turn result in unwanted reworks on the project, increased costs and project delays.

TIP 2 – Synchronization of your Business Analysis Plan with the Project Schedule

It is good to ensure that the activity dates of your Business Analysis Plan are incorporated or synchronized with the Project Manager’s Project Schedule. Nothing is worse than discovering that the period of time the project manager has allocated for your Business Analysis Activities is insufficient.

TIP 3 – Usually not all requirements can be captured up front.

Many Business Analysts discover that as much as the intention may be to capture all requirements up front before the execution phase, there are actually few cases where this is possible. During execution it is common that stakeholders bring up forgotten requirements.  The good news is that usually the Project Manager will define the Acceptance criteria with the client. The acceptance criteria is an agreement of what the product or service should constitute for it to be accepted by the client. The Acceptance criteria are usually part of the signed off project charter.  Other Project Managers may use the agile approach where prioritized requirements are implemented in phases. In summary A BA must accept the fact that in most cases not all requirements will be captured up front.

TIP 4 – Non Functional Requirements vs. Project Scope

As Business Analysts we also capture non-functional requirements i.e. the expected efficiency level of a system. It is good to liaise with your Project Manager on what is out of scope for the Project. It is common that non-functional requirements requested by stakeholders are sometimes not feasible due to budget and time constraints. In summary you need to be on the same page with your project manager on what is out of scope. This is to avoid complicating the management of your stakeholder expectations

 

TIP 5 – Help to minimize Scope Creep

As business analysts we know that stakeholders may request additional requirements during the course of the project. As Business analysts a new requirement is accepted or rejected depending on whether it can be directly linked to the Business Need. However Business Analysts need to remember that project manager aims to minimize new additions to the project scope (Scope Creep) that will require the adjustment of the Project budget and Schedule.  In most cases stakeholders are not willing to incur the increased cost or time required for inclusion of new requirements.

 

TIP 6 – All changes to requirements undergo impact analysis

Whilst carrying out the Requirements Management & Communications process the business analyst must ensure that changes to requirements go through the Impact Analysis process managed by the Project Manager. This is to ensure that the Impact that a change in requirement will have on the Project Schedule, Project Cost or product quality is assessed before the requirement change is formally approved.

 

TIP 7 – Collaborative Prioritization of Requirements

Prioritization of requirements is a standard task that we carry out as Business Analysts under Requirements Analysis. However it is common to reach a road block where stakeholders wish to classify all their requirements as high priority. This is usually due to the fear that non high priority requirements will be excluded in the project scope. With this in minded it is recommend that prioritization of requirements is done with the involvement of the project manager to assist in management of your stakeholders.

 

TIP 8 – Synchronize the list of prioritized requirements with the vendor selection criteria

Selection of vendors is procurement management task that critically requires the input of the Business Analyst. Selection of vendors is usually based on each vendor being evaluated against the vendor selection criteria defined by the project manager. It is crucial that Business Analyst ensures that the vendor selection criteria is synchronized with the list prioritized requirements.

 

TIP 9 – Transition Requirements can sometimes be implemented as post GO LIVE tasks

Business analysts also capture transition requirements i.e. the required training of users.  For a Business Analyst a project is complete when all the categories of requirements i.e. transition requirements have been implemented.  However what is sometimes experienced is the Project Manager wishes to separate the implementation of transition requirements from the Project Scope and treat transition requirements as post GO Live tasks. This is usually the case when Project has a non-negotiable constraint on the GO Live Date.

TIP 10 –Factor in Project Manager’s constraints and assumptions when the defining the solution scope.

The Business Analysts defines the solution scope under the process of enterprise analysis. It is critical that the Business Analysts gains the input of the project manager on constraints and assumptions before defining the solution scope.

 

CONCLUSION

To work effectively with Project Manager a Business Analyst has to be able to understand aspects of stakeholder analysis , Project Schedule , Project Scope ,  Managing scope change , vendor selection criteria and project constraints from the eyes of a project manager.



Newsfeed display by CaRP
Share this page


Follow Business Analysts