Select Page


Business Analysis – Part 2

Business Analysis – Part 2
By Keith MathisPM Expert Live

As we continue our look at the Business Analysis knowledge areas, this month we will look at the next two sections: Requirements Management & Communication and Enterprise Analysis.

Requirements Management and Communication

Requirements Management and Communication involves making sure that all stakeholders understand the nature of a solution and agree on the requirements that the solution will meet.

Requirements Management and Communication Tasks

  1. Manage solution scope and requirements – Obtaining and maintaining consensus among key stakeholders regarding the overall solution scope and the requirements that will be implemented is the first step to this knowledge area. All requirements must be assessed to verify that they fall within the solution scope. If additional requirements are invalid, the business analyst must resolve the difference.
  2. Manage requirements traceability – You will now create and maintain relationships between business objectives, requirements, other team deliverables, and solution components to support business analysis or other activities.

Read the Complete Article

8 Powerful Ways to Choose and Execute Projects

8 Powerful Ways to Choose and Execute Projects
By Harry Hall

Your company’s future is at hand. Select and execute the right projects and you will reach your greatest potential. Select the wrong projects and you will fall behind your competition—possibly crash and burn.

I have seen companies wrestle with the project selection process for years. Which projects should we choose? Do we have the right resources to execute the projects?

A sad but common story

Here’s a common scenario. Senior management has grand ideas on enhancing an existing product and leaping past the competition. The project sponsor has declared a six month project deadline.

The project manager expresses concern: there is insufficient information to determine whether the project can be delivered within six months. The project sponsor says we have no choice. Do the best you can.

The project manager kicks off the project with little understanding of what will be included in the product. Read the Complete Article

How Do You Know if Your Project Has Lost Direction or Risks Failure?

How Do You Know if Your Project Has Lost Direction or Risks Failure?
By Peter Osborne

Every program or project requires a clear and viable business case supported by effective sponsorship and proactive leadership if it is to be economically and expediently delivered. But these factors alone do not necessarily guarantee success. Peter Osborne of LOC Consulting identifies the fundamental areas in which delivery issues can arise, and discusses the five questions program sponsors should ask to establish whether a health check or recovery may be necessary.

  • Leadership – Are the right leaders with the right skills in place?

    Companies often appoint senior personnel to manage projects based on availability or cost, rather than experience or skills. If a leader isn’t suitable, the project and the team can lack clarity of purpose in that approach, governance flaws emerge, and people become disengaged with the project. At this point, the delivery culture fails and the project or program dissolves into disarray.

Read the Complete Article

How Are We Feeling Today?

How Are We Feeling Today?
By Russell Whitworth

The concept of a “project health check” is well known, and yet not widely applied. Which is strange, because in my experience it is one of the most powerful techniques for project assurance. Perhaps would-be practitioners don’t understand how to go about it? Or could it be seen as too much of an overhead? Maybe there is confusion between a health check and an audit – resulting in fear?

In this blog post, I will describe a simple and effective health check method; one that I have applied successfully dozens if not hundreds of times.

Performing a Health Check

The basic format is this. The reviewers sit down with the project manager for a 2-3 hour meeting, and hold a structured conversation regarding the project. During the course of the conversation, the most relevant issues facing the project are discussed in detail, and brief findings and recommendations are written down. Read the Complete Article

Risk Management… The What, Why, and How

Risk Management… The What, Why, and How
By Michael Stanleigh

What Is Risk Management?

Risk Management is the process of identifying, analyzing and responding to risk factors throughout the life of a project and in the best interests of its objectives. Proper risk management implies control of possible future events and is proactive rather than reactive. For example:

An activity in a network requires that a new technology be developed. The schedule indicates six months for this activity, but the technical employees think that nine months is closer to the truth. If the project manager is proactive, the project team will develop a contingency plan right now. They will develop solutions to the problem of time before the project due date. However, if the project manager is reactive, then the team will do nothing until the problem actually occurs. The project will approach its six month deadline, many tasks will still be uncompleted and the project manager will react rapidly to the crisis, causing the team to lose valuable time. Read the Complete Article

AIP and The SAP Business ONE Project Lifecycle

AIP and The SAP Business ONE Project Lifecycle
By Eduardo Levenfeld

If you’re already someone with some experience in project management, but you have just started your first experience in managing a SAP Business One Implementation project (like me), then I hope this post contribute with the success of your project.

A first and good step

First of all, a good first step is to get access permissions to browse the SAP’s PartnerEdge portal and the SAP Community Network (SCN) (usually the person the person in your company who has the admin/manager permissions will grant you those permissions). There’s a lot of awesome and useful content there. So, go ahead and make sure you have that access.


  1. ASAP

    Ok. Now you have permissions to navigate in SCN and PartnerEdge, let’s start talking about the ASAP, AIP and other acronyms from the SAP ecosystem.

    When you read about ASAP in the SAP universe, it usually stands for the Accelerated SAP Methodology that is a well defined and documented methodology and set of templates and processes focused on the project management activity in an SAP implementation.

Read the Complete Article

How to Write a Fantastic Digital Project Brief

How to Write a Fantastic Digital Project Brief
By Nina Epelle

Are you about to kick start a brand new digital project? Or have you just joined an existing one and are in the process of gathering project information? If so, pause for a minute. A Digital Project Brief will set you and your team off to a good start…

As a Digital Project Manager, whenever you’re embarking on a new project, it is always sound practice to create a Project Brief. This is one of the key elements that helps you communicate with your wider project team and ensures that throughout the life of the project you maintain an aligned view on why you’re there and what you’re supposed to be doing. The Project Brief also helps you, the Digital Project Manager, verify that you’re thinking along the same lines as the Project Sponsor and/or Client, and that you are all in complete agreement on to how to proceed. Read the Complete Article

Key Content for Project Kickoffs

Key Content for Project Kickoffs
By Kiron D. Bondale

Holding a formal project kickoff is generally considered to be a good way to get everyone aligned to a set of common goals and practices at the start of a project.

I’ve always found the word kickoff to be somewhat inaccurate as that brings to mind the organized chaos which ensues in a football (American or otherwise) once the referee blows their whistle. I prefer to use the analogy of runners in a relay race waiting at the start line for the starter’s gun to be fired – a high-level of activity, but everyone running in the same direction and focused on getting their sprints completed as quickly as possible with highest quality.

If you are preparing for your project’s kickoff meeting, it can be daunting to come up with a short list of topics to cover – for many attendees, it might be their first formal exposure to the project so there is so much you will want to share, but you only have an hour or two to do so. Read the Complete Article

How to Measure the ROI of Project Management Software

How to Measure the ROI of Project Management Software
By Jesse Jacobsen

Keeping projects under budget is no easy feat. In fact, around 85 percent of projects go over budget. The idea of unnecessarily investing funds in project management software that results in no significant – or worst, negative – return on investment (ROI) is just too risky for many managers. Before purchasing any sort of PM solution, it’s important for you to be confidence that your investment will have a significant return.

Unfortunately, determining the ROI of implementing PM software isn’t as simple as plugging numbers into an equation. The tools and benefits that PM systems provide are often difficult to quantify on an individual basis.

Some project management vendors include ROI calculators on their website that help determine your return based on information about your company and typical projects.

While these can be a good reference, there are many inherent flaws with relying too heavily on their calculations. Read the Complete Article

The Details Needed in a Business Requirements Document

The Details Needed in A Business Requirements Document
By Michelle Symonds

A Business Requirements Document is typically used for complex projects so that everyone involved understands what the aim of the project is and how that will be achieved. It also documents what features and functions will be included in the project as well as sections on risk, assumptions and quality control.

It also documents how an end-user will use the final deliverable to achieve the business aims. For that reason it will contain information about the features and functions of the new product, process or software.

One of the important aspects of a BRD is to understand that it will be read by people with no technical knowledge and has to be understood by those people (as they will be approving the document). For that reason it should not be full of technical jargon (there are other technical documents that can fulfill that purpose) – it should be easily readable and as short as possible but, at the same time, it must explain in some detail how an end-user will use the project deliverable. Read the Complete Article