Resource Library

Traditionally, ITIL and TOGAF professionals have been part of different teams within an organization. Due to the ongoing alignment of business and IT, these professionals now often find themselves on the same team. Because of this crossover, there is a growing trend towards organization of work based on multiple best practice models. 

In the last two posts I discussed aspects of services in the context of some landscaping work that I’m having done. This is clearly what many people would call a “non-IT example.” I often use similar examples in my classes. However, I might initially describe an example that seems unrelated to IT, but will conclude with a challenge to students. That challenge is, “identify the IT in this example.” The truth of the matter is that most businesses these days are underpinned by some form of information technology. In fact, technology has become so ingrained into everyday services that often even the service providers themselves don’t realize how technology supports their business.

When designing a structured business analyst interview, it’s crucial to have a goal in mind, a clear set of questions planned, and an understanding of how those questions may deviate from the intended goal. An interview has an intended line of questioning; it may also have alternate lines of questioning and unanticipated paths where the interviewee has raised issues or answered questions in a way the business analyst had not considered or planned. In short, an interview is a social process.

Effective requirements collection at the outset of the project is the key step that will ensure that the project manager can deliver what is actually expected. In this respect, the business analyst must become a key ally and advisor to the project manager. Most project managers are not trained business analysts, so taking advantage of the skill set that a business analyst can offer can greatly enhance the possibility of project success.

Successful transformation initiatives are driven by Business Architecture. The Business Architect plays a key role in bringing all of the portfolio components together and consistently reinforcing senior management's voice throughout the ADM lifecycle. This begins with establishing strategic goals and outcomes that set the context for the entire program and service transformation. Establishing context serves as the basis for strategic project portfolio definition and integrated execution. This approach mitigates the risk of executing projects in isolation without considering the needs of the entire portfolio as a whole. This session will boost your knowledge of these concepts and help you and your team to achieve the best possible outcomes for your organization.

Being able to play both roles of a project manager (PM) and a business analyst (BA) is a great skillset to have. Learn how to ensure your team gets what it needs in these two key roles so that you all can deliver successfully.

Communication is vital within projects and contributes significantly to project success. PMs and BAs have important—and different—roles. Let's take a look.

Whether you're a Project Manager or a Business Analyst, you can certainly relate to a situation where you've felt like your cohort on a project was from a completely different planet! This panel discussion webinar between our PM expert, Ori Schibi, and our BA expert, Cheryl Lee, will explore some of the misconceptions that each role has and learn how to play nicely with each other in the project world.

The demand for skilled business analysis (BA) professionals is on the rise, and a great way to declare your expertise is with a BA certification. But which BA certification is right for you: PMI-PBA, CBAP or CCBA? Here is a look at the eligibility requirements and steps for obtaining each.

We build requirements at a quantum level to connect the vital elements, which are needed to realize a requirement. As we consider the relationships between the behaviors, actions, and responses, we begin to identify and associate the characteristics and conditions, which will drive and constrain the behaviors. Realizing a requirement means joining these elements together and noting them as elements of the requirement.