Tag: Planning

Key Variables to Remember When Planning Projects

Written by Brad Egeland on February 8, 2018. Posted in Articles.

No surprises, no variables, nothing changes during the life of a project, right?

Sure. Raise your hands if you’ve ever managed a project that hasn’t experienced at least one change order / scope change. No hands? Didn’t think so. I know I haven’t had one and that isn’t a indication of poorly performed requirements definition efforts or poor scope management. It’s a case of long projects fleshing out slightly more complex or detailed requirements along the way and the delivery team ==> customer team relationship evolves and the delivery team’s (and customer team’s) understanding of the business processes and needs in play and the “as is” vs. the “to be” environment becomes clearer.

So what varies from project to project that can affect the project, the planning, the schedule, the budget, the requirements, the templates… maybe even the methodology and how you manage the project. After all, projects are never really cookie cutter projects, you need to look at each one uniquely anyway, right?

The customer.

Obviously, the physical customer varies from project to project – although you may end up running several projects over a period of time for the same, satisfied customer… and that’s aways a good thing. They only come back if they’re happy – and have budget for it. And with the varying customer comes varying needs, varying wants, varying neediness, varying wishes, varying awareness of their own business processes and requirements, and varying understanding of technology and the necessary solution. Some customers will participate as if they are part of the delivery team and some may disappear for most of the engagement because they either don’t have the time to be involved or don’t have the inclination to be part of the actual project work and progress.

The money.

Certainly the money varies with each project engagement. Every project has it’s own budget and, likewise, every client has an amount of money available that they are willing to spend on your services. My favorite client is the one who understands the value of the offering and isn’t trying to get the cheapest deal or project proposal possible. You can make yourself the cheapest option when you are trying to land a project and bring a client onboard, but that doesn’t make you the best and may actually weaken your ability to deliver on the project. Funding for the project may be so low that the project won’t be a high priority for the organization, making resources and time devoted to the project hard to come by and therefore your ability as the business analyst hard to deliver on. That’s a lose-lose.

Likewise, you don’t want to be trying to overcharge a client either – give them a reasonable and accurate price. Then wait.. and listen. Don’t negotiate to a lower price if it will mean you lose money unless landing this particular project customer is truly worth such a scenario. Be ready to say “yes”, “no”, or “let’s talk” depending on how bad you want this project and how flexible you can be. It’s always ok to say “no” and walk away.

The team.

Your project team is going to vary from project to project. In a matrix organization, you’re going to work with some team members over and over again, but the overall makeup of the team will likely never be exactly the same again – depending on how large your organization is. So, it’s a given that the talents, emotions, collaboration, cohesiveness, and accountability will vary somewhat from project to project and team to team. And just because you have 90% of the same team back from a very successful project for the next project… don’t assume that the new 10% will just fall in line and be just as successful and collaborative, and team oriented and cohesive. They may actually become combative and cause other team members to be less productive, efficient and cooperative as well. You’ve heard the phrase “One bad apple can spoil the whole bunch.” That can also be true of the project team. So the good business analyst needs to be able to recognize team chemistry and never take for granted or assume that team members that worked well together before will be able to replicate that – even if there are no new team members. Be ready to deal with conflict and confront team resource issues head on.

Key assumptions.

Documenting, clarifying and revising assumptions before the project, during kickoff and throughout the full engagement is critical to success. And assumptions are going to vary from project to project. In fact, as the experienced business analyst on the project, you are likely going to be in the best position to document key assumptions for most projects as you have both a technical understanding and a project management strategy and delivery understanding of the project as a whole. Assumptions on a technical project are not just technical in nature, but also involve vendors, risks, and even input and actions of the customer and supervisors. The project manager, customer team and tech team will also be key managers of assumptions throughout the engagement.

Outside vendors.

Outside vendors on any project can present a wildcard type of affect – and the vendors as well as their level of affect and impact on any given project will vary from project to project. The database supplier on a pharmacy or medical project – with all of the related HIPA issues and drug / prescription information is very different than the database supplier on tools and car parts information. The variance can be great from project to project and from industry to industry.

Risks.

Finally… those risks. Several risks are going to be a given on every project and should probably be hard-coded on to your project risk registry as you begin the risk identification and management process. But many of the detailed risks are going to depend on the vendors used, the technology used, the requirements of the project, the customer’s environment, and the project team… just to name a few. The business analyst and the project manager – actually all stakeholders – need to play a part in that risk identification process and the overall risk management process… it’s too important not to do it right and dedicate the proper time and effort and dollars to the management of those varying risks.

Summary / call for feedback

I realize this is just the tip of the iceberg in terms of what varies from project to project as no two projects are exactly the same. But I think this is a good start on some of the big ones and more obvious ones that will vary no matter what the project is or what the industry is.

Assessing Requirements in Requirement Gathering Sessions

Written by Poorti Mehta on January 25, 2018. Posted in Articles.

For a Business Analyst a project begins with requirement gathering or eliciting requirements (a popular term used to describe this task).

Workshops, interviews and brainstorming sessions – the more a Business Analyst conducts these methods of requirement gathering, the clearer a picture gets to him / her. Amidst these exercises, how important is it for a Business Analyst to simultaneously analyse a requirement or rather weigh a requirement? In other words how necessary is a requirement?

Although a thorough analysis is undertaken once all the requirements are gathered, it does help if certain requirements are assessed at the time of requirement gathering.

In one of my recent sessions certain high level requirements were discussed. These requirements were for an application that was requested to be developed for an internal sales team. Post the overview began the requirement gathering. I had my set of questions ready and took up one module at a time. A couple of minutes into the session, just as I was about to jot down one requirement, there came an opinion from one of the stakeholders. An experienced IT professional who has been associated with the organization for about 15 years and who is an SME on Financial Technology, begged to differ with this requirement. He posed some very important questions:

Is the requested feature really required?
What if there were an alternative? What if the purpose could be solved with a slightly different form of the feature?
The time effort and cost analysis if this requirement were worked upon and the time effort and cost analysis if an alternative were developed.

Now it took some solid ideas for the SME to convince the stakeholders to alter the requirement. All the stakeholders dug deeper into analysing the actual ‘requirement’ of this ‘requirement’.

To sum up an alternative was agreed upon. This alternative served the purpose of the business stakeholders, was economically feasible and could be developed in lesser time all without compromising on the quality of the application and the purpose of the feature.

Not all the requirements that are put across have the same nature. But there could be times when the business users are hell bent on having a complex feature in the application or they may want to implement a module on an existing application just because they happened to experience a fancy feature in the application of a competitor. While some requirements may be very helpful to the business, there may be certain requirements that can be optimally altered.

Requirement Gathering shouldn’t be about just jotting down requirements – Some requirements may not be needed at all or there may be better alternatives available. Such alternatives should be put on the table and discussed. The following questions can be asked:
- How purposeful is the feature / requirement?
- If the requirement is essential but it will take a lot of time to develop what can be done to deliver an alternative?
Stakeholders may come from either a technical background or a non-technical background – Some of them may be from a non-technical background but may possess a sound technical knowledge. However, if a stakeholder is from a non-technical background and doesn’t know the development process thoroughly, chances are high that a Business Analyst will have to discuss a requirement in more detail. They may not know the development process thoroughly. But you do. You know how much effort goes into developing the smallest of module of an application.

A stakeholder may not be completely aware of the time taken for development or the cost involved in undertaking the development of a module and making changes. In such cases, a Business Analyst has to dive deeper and ensure that the requirements serve the purpose of all.

In most projects, requirements undergo frequent changes – Stakeholders expect to go live with a product with almost all the requirements raised by them; even the changes. However given factors such as cost time analysis, project development time frame, priority of the project and availability of the resources deployed, it may not be possible to involve all the features during the launch. The requirements thus need to be prioritized keeping in mind the interests of all the stakeholders. While the major requirements can be taken in the first phase, the remaining can be put into the subsequent phases.
Requirement Gathering along with simultaneous analysis helps to save time during documentation and consequently project planning – If a doubtful requirement is discussed then and there and the alternatives are weighed, the stakeholders can reach on a consensus and consequently the requirement can be clearly documented and closed. This saves a Business Analyst from consequent follow ups required for requirement clarity or discussing changes.
A project may seem to be a simple at first however it’s only when these requirements are thoroughly analysed that the complexity of the development can be understood. Thus questioning a requirement in the interest of project development is important.

Weighing requirements is as essential an activity as requirement gathering. If done in the initial requirement gathering sittings, the subsequent processes – requirement documentation, sign off and planning can be smoothly accomplished.

Business Architecture in an Agile World – the What and the How.

Written by Scott Comte on January 11, 2018. Posted in Articles. 1 Comment on Business Architecture in an Agile World – the What and the How.

My current, favourite question for Executives and Architects is “How do you see Architecture operating in an Agile environment.”

This question usually elicits a wry smile and a response along the lines of “I will need to get back to you on that!” Many people are wondering how Architecture will fair in the world of Agile. My answer is I believe very well!

Originally developed to deliver improved outcomes in software development, Agile was the hot management trend for 2017. There are a number of drivers behind this trend, but fundamentally executive teams are looking at new ways to deliver business outcomes and to create value in an environment of increasing complexity and disruption. They see Agile as a way of shaking up old paradigms by empowering their people to be more accountable for delivering outcomes and less constrained by traditional management frameworks and practices.

The principles of Agile are very straightforward. Agile methodologies focus on the following:

Individuals and Interactions rather than processes and tools
Working Solutions rather than comprehensive documentation and project plans
Customer collaboration rather than contract negotiation; and
Responding to change rather than following a plan.

For executives who are operating traditional bricks and mortar business and are seeing their core markets being picked off by smaller and more nimble competitors this is heady stuff. Agile promises a way to breakdown intractable bureaucracies and take on the new-comers at their own game. However, many organisations have learnt Agile won’t deliver the outcomes that executives want on its own. There needs to be something that focuses all of the creativity and energy engendered by the Agile way of working so that demonstrable business outcomes can be achieved. That something is Business Architecture.

For organisations there are three key questions that need to be answered. Why do we exist, What do we need to achieve and How will we do it! Most organisations are clear on the Why question which is usually articulated in their Mission and Vision statements. Most often this is determined by the board and/ or executive teams and communicated to management who then have to figure what they need to achieve to deliver and how are they going to do it.

I see Agile and Business Architecture as the perfect combination to answer these questions. Business Architecture answers the What needs to be done question while Agile provides an approach as to How outcomes will be delivered.

Business Architecture defines the business model, value streams, capabilities and initiatives (projects) required to deliver strategic outcomes, while Agile leverages the creativity of staff, and the ecosystem in which the organisation operates to find more innovative and efficient ways to deliver strategic outcomes.
Business Architecture takes an organisations strategic intent and defines not only what goals/ objectives need to be achieved but what needs to be done to achieve them. It provides a reference framework in which Agile approaches can operate and ensures that the outputs from the Agile processes are contributing to the organisations strategic goals.

So as Business Architects why do we need to care about, and understand, Agile. The reason is that no matter what our functional expertise, our core purpose is to deliver outcomes for the organisation. In the current environment Agile is fast becoming the preferred methodology to deliver outcomes.
In a recent CIO article on IT project success rates the author Sharon Florentine cited research from the Project Management Institute (PMI) that showed that success rates for IT projects are finally on the rise. The interesting insight as to why success rates are increasing is that organisations are measuring project success in what the author describes as a more mature manner. That is rather than looking at measures such as was the project delivered on time and on budget, they are measuring whether the project delivered the benefits that were required by the organisation. To put it succinctly ‘there is less focus on the means by which a project is deemed successful and more on the end: does the project deliver the business benefits promised?” This has been driven quite significantly by the blurring of the lines between IT and the business with many projects becoming more cross functional and multi-disciplined in their approach, which is fundamentally the Agile way of working.

This is not to say that business benefits weren’t considered as part of the traditional measure of project success but they were usually assessed once the project had closed. If the business environment and/ or needs had changed during the project lifecycle this measure may have become less relevant or in some extreme cases irrelevant. With Agile, organisations are looking at benefits (value in Agile terminology) right from the beginning of the project and they are constantly benchmarking their project outcomes against the required benefits. It all makes intuitive sense, which is why Agile is being embraced by so many organisations, but it does beg the question what are these benefits and where are they defined. In my opinion, this is the core role of the Business Architect.

I mentioned earlier that the reason that executives are embracing Agile is that they want to drive change within organisations so that they can compete and thrive in increasingly fast paced environments. They are committed to this course of action as their professional wellbeing is contingent on achieving this change. This is a golden opportunity for Business Architects to be key drivers of this change by filling the crucial role between strategic intent and Agile execution. It will require Business Architects to question and modify some practices but I see Business Architecture (the What) and Agile (the How) as a valuable combination to drive organisational performance.

Planning Workshops Using the 7Ps Technique

Written by Ryan Hewitt on January 2, 2018. Posted in Articles.

It’s difficult to plan for a workshop. There’s so many things to consider, sometimes it’s hard to know where to begin!

The best technique I’ve used for planning workshops is called the 7Ps. I found it in an excellent book called “Gamestorming”.

I use the 7Ps to create a clear agenda & make sure I’m prepared for a workshop.

How’s it work?

The technique asks you to consider the following areas for planning a workshop:

Purpose – why are you having this session? I tend to write 3-4 bullet points to summarise the purpose. This is the most important question & worth starting with
Product – what artifacts do we want to come away with from the workshop? You can think about this as outcomes or deliverables
Process – what will the agenda be? This should tie back to the purpose. The process needs to ensure you achieve the purpose & come away with the products you want
People – who will be in the session? And equally important – what role will they play? What kind of questions will they be there to answer? Will one person represent the technical side of the business. Will one person be there to sign-off the scope?
Pitfalls – what are the risks of the meeting? E.g. a particular question that might blind side you, that some people will want to delve into detail. Think about these pitfalls & write down how you’ll mitigate them
Preparation – what do you need to in advance of the session? E.g. do you need to create a presentation deck. Do you need to bring information to the meeting?
Practical Concerns – these are things around logistics. Where’s the meeting? Do you have a TV? Who will meet the visitors etc

Working example

Below is an example of how I recently used the 7Ps.

I was planning for a workshop with a new vendor. We wanted an all day session to convey our initial requirements & allow the vendor to feedback on what they could deliver in their first release. It was also our kick-off session for agreeing how we’d work together on delivering a service.

I sketched out the below 7Ps and sent it to our team for internal feedback.

Purpose – 3-4 bullet points felt like the right level of detail. The above purpose was what I wanted to get from the meeting; however I also considered what others / the vendor would want to get out of
it. It’s always worth thinking about other people’s expectations. I start on this section first – because that drives everything else
Product – I find this to be the hardest section. In this example the product was a collective agreement of scope & how the scope would be delivered. The product was a NOW/NEXT/LATER roadmap which would be updated in the session. Sometimes the product isn’t tangible (e.g. getting everyone to understand why you’re making a change)
Process – this was the next section I filled in. After identifying the purpose & product, I thought about what an agenda might look like / a typical running order. Each item here contributes to the purpose – and ensures we come away with the right products. Tieing the process back the above ensures that agenda items are necessary and add value
People – this is always really useful. Sessions shouldn’t have more than 10 people. It’s useful to think about who needs to there – and what their role with be. A role might be: to answer technical questions, to represent the product team, to answer any questions around operations, or it can be a job title
Pitfalls – I try to think about likely pitfalls. For our session, it was that that we would be drawn into the detail, and that we’d be asked a specific process question which we didn’t know the answer to. We actually invited the SME to mititgate that pitfall. And we created a question board where very specific questions could be parked
Preparation – who will create the assets before the workshop? What will they create & bring? I put names & deliverables in this section for our workshop
Practical Concerns – these are often things that people forget about. For our meeting it was: booking people onsite with security, checking the room has a TV, booking a room all day so that we could setup ahead of time. This became a checklist to make sure we were ready to run the workshop

Summary

I find the 7Ps a really good technique for conducting focussed workshops.

I typically use the 7Ps on my own to create an agenda, then take a picture and get people’s thoughts. This way attendees can feedback on the agenda. I find the “Process” & “People” sections are particuarly valuable for getting feedback & co-designing an agenda.

I find creating a physical version of the 7Ps means I can cross things out & move between sections easily. I often move from one section to another – and back again – as its all interconnected.

Hopefully you found this article interesting. And it’s a technique you would consider when planning for large workshops 

A Business Analyst’s song

Written by Mark Owen on December 21, 2017. Posted in Articles.

I am the very model of a modern Business Analyst

I’m a planner, a doer and a damn good strategist
I talk with stakeholders, end-users and management
From C-level to staff and also contaminant
I’m well acquainted too with the elicitation of requirement
Ensuring that between the parties there is always a good agreement
Although to make that happen is sometimes quite an achievement
It’s all done with a smile right up to the completion.

I’m very good at analysing, interpreting and modelling
To present the data, and the findings in a way quite compelling
In short, for a project, you need me as a panellist
I am the very model of a model Business Analyst

I work with teams – both agile and waterfall
And sometimes is the process almost unbearable
Often is it important all questions in depth to discuss
To ensure that the result achieved is without much fuss.
I’m good at observation, root cause analysis and can make a sequence diagram.
As well as run a workshop, interviews and a collaborative game.
Then I can conduct, coordinate and plan to understand.
Exactly what the sponsor, stakeholders or Product Owner really demand
Confirming that with the team, through a document, a backlog or a story board
So that work can begin, and any necessary changes can be explored.
In short, for a project, you need me as a panellist
I am the very model of a model Business Analyst

In fact when I know the difference between a use case and a user story,
When I know that CATWOE and Gap are two analyses of a different category.
When such affairs as office politics and stakeholder conflict
I know can the process of reaching a solution really restrict
When I have understood the concepts of the Business Analysis Core Concept Model
And know that Agile and Scrum are not a load of twaddle
In short when I’ve more than a smattering of Business Analysis Techniques
You’ll say never has a better Business Analysis had better critiques.
For my business analysis skills, though I’m plucky and mostly agreeable
And because of that I think you know that it is most foreseeable
That, in short, for a project, you need me as a panellist
I am the very model of a model Business Analyst