Tag: Training

How To Take Your Project Management Strategy To The Next Level

Written by Frank Hamilton on September 26, 2019. Posted in Articles.

Project management has always been a fundamental element of any business.

If the company executives don’t have a grasp of the key components of what their organization is doing, everything will go wrong. Here’s how you can take your project management strategy to a whole new level.

What Is Project Management About?

To put it simply, project management is about applying certain knowledge and skills as well as tools and techniques to meet specific project goals, objectives, and deliverables. It includes all the inputs and outputs that project managers and teams may use.

The goals that project management pursues can include anything from identifying and executing initiatives to acquiring the right people. It’s actually quite a broad term, but the concept is that project management professionals help achieve certain company goals by driving, guiding, and executing them.

How to Choose the Right Methodology?

In order to be able to execute your project properly, you must know and choose the best methodology that could be applied to it. Of course, it’s better to use hybrid project management methodologies for better results. Here are some of the most popular project management methodologies (PMMs):

Waterfall: The project is completed in separate stages and moves one step at a time toward the final destination which is the release to consumers.
Agile: Sprints, or short development cycles, are used to focus on continuous improvement and development of a certain product or service.
Hybrid: This method combines agile and formal project management methodology.
Critical Path Method: The most important tasks are identified from the beginning and performed prior to the tasks that can be slowed down and performed later.
Critical Chain Project Management: The method emphasizes resources such as people, equipment, and physical space needed to complete the project.

When choosing the methodology you will be using in your project management, you must keep in mind all the peculiarities of a specific project. Sometimes, you will need to use one methodology while other times you will be using something else. In addition to that, don’t forget that you can combine them from time to time if the situation requires it.

What Are PMO and EPMO?

PMO or project management office and EPMO or enterprise project management office are both umbrella organizations that companies codify project management efforts under. Both of them have some notable differences and similarities to keep in mind:

PMO: Usually doesn’t play a lead role in strategic goal alignment. It’s an external or internal group that sets directions and maintains standards, best practices, and project management status.
EPMO: It is increasingly being adopted by companies. EPMO has the same functions as PMO, but it must also align the project, program, and portfolio activities with the company’s goals.

Both PMOs and EPMOs offer more visibility throughout the organization, ground rules for the project teams, a common language for all the team members, key indicators to measure project performance, more agility and adaptability, and the ability to identify the status of various tasks.

What Are the Key Roles In Project Management?

The positions that will have to be filled by different professionals in your project management strategy will vary depending on the project, methodology, company, team, and industry. You may need the help of such people like business analysts, schedulers, sponsors, functional leads, business intelligence analysts, and others.

To get you started, here is an overview of the three key roles in the management of any project:

Project Manager: Plans, executes, monitors, controls, and closes individual projects. There can be one or more project managers in your organization.
Program Manager: Oversees and leads a group of projects that are similar in nature. Project managers will usually report back to program managers.
Portfolio Manager: The highest level of PMOs and EPMOs. Oversees the strategic alignment and direction of projects and programs. Program managers will usually report back to the portfolio manager.

What Skills Are Important In Project Management?

Project management professionals must possess a combination of technical and non-technical skills in order for the project to be a success. They must be able to adapt and find creative solutions to overcome challenges. Here are the seven key characteristics of successful project management professionals:

Leadership: A good leader will be able to unify all of the team members and lead them to their aim.
Communication: Communicating well with your team members is essential for the coordination of all the tasks.
Motivation: Being motivated means that you will not only find ways to keep pushing on but will also be passionate about the project.
Organization: In order for everything to go smoothly, a project must be well organized with everyone doing their job.
Problem-Solving: Solving problems and overcoming unexpected challenges is crucial for your project to be a success.
Adaptability: Adapting to a new environment will help you stay up-to-date with the latest conditions and keep evolving.
Prioritization: It is very important to prioritize your tasks and do the most urgent ones at the beginning.

Final Thoughts

To sum up, project management may seem like something unimportant but it actually plays a major role in the processes within any business. Follow the tips in this article to make your project management better and more effective.

99 Tips to be a Fantastic Business Analyst

Written by Bronia Anderson-Kelly on August 29, 2019. Posted in Articles. 3 Comments on 99 Tips to be a Fantastic Business Analyst

1. BA yourself

This is one thing that only some professions can do. An Actuary can’t actuary himself, a developer can’t code herself, a mechanic can’t mechanic himself. We can analyse ourselves. Use your skills. Decide what a fantastic BA is; research, interview, question and then review yourself. Do some gap analysis and then formulate an action plan.

2. Be nice

No one wants to work with a jerk. No one wants to help and supply information to a jerk so engender support. Thank people, go out of your way to be personable, establish friendships and mutually positive working relationships.

3. Understand project lifecycles

Get to know all the steps in project lifecycles, not just your own and especially the intricacies and peculiarities of the adaptation used by your organisation.

4. Be a mentee

There is much to be learned from Analysts further along the road than you.

5. Present well

Don’t dress like a scruff, smell nice, clean your teeth. These are surely basics but I have met people in business who have overlooked these things and they are avoided. You can’t be avoided and be successful.

6. Prep prep prep

When you go to meet a stakeholder, especially for the first time, prepare. Understand who they are in the business and project context. Ask them for any pertinent information to be sent for your review in advance. Maximise the time with them to appear (or be) effective and efficient and they will happily give you more.

7. Be on time

Your prompt arrival in the office and at meetings will give you more poise than if you rush in late. It is the fruitage of an organised and self-correcting individual.

8. Work on your confidence

We’re not all naturally confident but by reassuring ourselves of our abilities in our BA skills or in our industry knowledge we can instil the needed confidence and trust from our business stakeholders that we can understand their world view and needs.

9. Don’t reject difficult things

They help you grow. Be the BA that accepts unusual assignments and see your career enriched and flourishing.

10. Get good at cost benefit analysis

Don’t leave this to the PM. At project inception, or for minor changes, be able to determine with appropriate certainty whether to accept or reject activity. Maintain a project which can stand-up on its own merits.

11. Be optimistic

Pointing out the bad may be necessary but if you find yourself always the nay-sayer then fix it. Problems are our business. Our optimism can make for a gentler change process.

12. Get your desk in order

Give your workspace a make-over. Keeping it clean and orderly can help you be organised and looks a lot more respectful.

13. Go to a conference or two

Hear some new stuff. Mingle with your peers. Feel proud to be part of a greater something.

14. Help others

You have a project deadline, sure, there’s always one looming but give your fellow BAs your assistance. It will broaden your knowledge and strengthen your team.

15. Be strict about your change management

Keep a record of changing requirements and details about them. It will save you the red face when, inevitably, someone will ask you later for paperwork.

16. Do your actions

If the PM has to continually chase you for your actions they will resent it.

17. Don’t be offended by the red pen

Your work will be reviewed, heavily. Welcome critique and correction. Never be upset about any proposed edits. The individual has spent time immersing themselves in your work and for that you can be grateful. It will make your work better, or at least more acceptable to your audience.

18. Volunteer to share your knowledge

Blog, post, present at lunch-and-learns, write-up how-to guides. There are always people who don’t know what you know so share.

19. Model

Use models a lot. Business people invariably find models easier to verify than paragraphs of information and it brings the potential delivery to life. Architects, Developers and Data Analysts thrive on a well-produced model.

20. Learn, learn and learn some more

If you have the means then don’t stop learning. There is so much training available in BA skills, industry knowledge, peripheral project skills, business knowledge, techniques and soft skills.

21. Offer plentiful walk-throughs

By walking-through your outputs with developers, testers and business representatives you reduce the risk of misinterpretations.

22. Finish your projects

This is especially true if you are a contractor. It’s not good practice to leave a project part-way through if you can help it.

23. Develop strategies for juggling

You will have to work on many things at once. Find what works for you to avoid loss of productivity. If you have yet to nail this there are plenty of productivity tips and hacks on the internet.

24. Clear paths for people

Be someone who anticipates down-stream problems and blockers for yourself and others and intervene.

25. Categorise people but know your exceptions

Use personality and character traits to help you understand the motivations and reactions of your team but note that exceptions exist. Tailor your interactions to fit.

26. Don’t jump to solutions

Have problem-formulating conversations to focus your mind away from solution-mode.

27. Form collaborative relationships

When you collaborate you are more likely to get early and continuous buy-in, nothing will come as a surprise to your end client and you get immediate feedback on your work. It’s worth the extra effort.

28. Find your key SME voices

The quality of Subject Matter Experts is not equal. I have seen business users hide information for a variety of reasons (most understandably) making elicitation more than the usual effort and I have had System Testers guess answers and present information as fact. Hunt for good sources of information and verify what is said.

29. Play requirements back

Saying things like: “So if I understand this right, what you needs is…” saves misunderstanding.

30. Work to uncover implicit requirements

What assumptions have you or your customers made that they haven’t vocalised. Set aside some time and thought to uncovering these.

31. Know your audience

The level of detail that you go to should reflect your audience, know this before you start your elicitation. Get it wrong and you either waste time or have to re-work.

32. Recognise that accuracy is important

Particularly in your written English. If you can’t get that right, what else might get called into question.

33. Start with context

Ask: “Why the project exists?”, “What will be the end results?”, “What benefits are sought?” Then work from there.

34. Document what you won’t build..

..and get it agreed. It doesn’t mean it can’t be changed but it will at least be recognised as a change rather than something that you missed.

35. Get creative

With care not to promise an outcome, suggest ideas and alternatives to users during elicitation. Possible options can be used as a sort of model to tease out other requirements.

36. Read widely

The IT industry is constantly changing and working practices follow hot on the heels. Our understanding of business practice, psychology, methods for collaboration and effecting change progresses. Manuals, how-to guides and handbooks to support our work are plentiful.

37. Don’t forget your non-functionals

If you don’t include these in your document template as standard, add a section for each non-functional as a reminder to consider it.

38. Don’t gild the lily

It may not be scope creep as such but it’s easy to gold-plate our requirements with unnecessary items. Admirably this is usually in response to wanting to deliver the best but these types of extras add up. Work out what your Minimum Viable Product is and then be sure to note any additions as just that.

39. Revisit your prioritisations often

Work with your group of SMEs to get your product features delivered in the right order but remember that things change so schedule re-prioritisations throughout delivery.

40. Evaluate your own skills

Choose a couple of areas for improvement, write them down and formulate some actions that will help you improve them.

41. Look for “free”/cheap benefits

By knowing what’s off-the-shelf or can be achieved with relative ease you can maximise the product and minimise the cost.

42. Ask for feedback

At suitable points during and at the end of projects get personal feedback. Asking people who will give you constructive critique is valuable. Keep it. In years to come you can see how this helped you to change and grow.

43. Find balance

Don’t neglect your personal life. Finding a good work-life balance helps you cope with the ups and downs of projects.

44. Connect with others

Associate with other Business Analysts. Everyone knows different things and that diversity is valuable. Learn, share, help and be helped.

45. Know when to shut up

You’ve raised a risk or an issue but no action has been taken, so you raise it again or differently. It’s good practice to be assertive but there comes a point when you have sufficiently noted it and taking it further causes consternation. Learn where that point is and stop before you reach it.

46. Be a mentor

You know more than you think you know. Give back to the profession by sharing that with someone following in your footsteps.

47. Work as a team

When you work with other BAs, even if you’re tasked on different items, work together. Peer review, support, offer and ask for opinion and share experience.

48. Make your research visible

If you do background reading, conduct surveys, read manuals, hold workshops then put your findings as links or appendices to your documents. Don’t make someone who may need to pick up your work at some later point have to start from scratch.

49. Expand your comfort zone

Do something a little bit uncomfortable, just a little. It will make you capable of more in the future.

(See www.batimes.com/articles/personal-growth-through-discomfort.html)

50. Be agnostic to the solution

If you begin with a pre-determined solution or have a particular software package in mind you won’t be working on behalf of your client.

51. Be flexible to software development lifecycles

Learn to work waterfall, agile, fragile, whatever your client wants. Help them build on what they have.

52. Work with positive people

When you get a choice, pick to spend your work hours with optimists. Lift your chin up and thrive with them.

53. Don’t plagiarise

It’s fine to get inspiration from other text but word them in your own way. The process of breaking something and re-working it allows you to assimilate it properly.

54. Create your own templates, improve others

If templates don’t exist within your organisation start to build a repository as you work. Have one eye on how a future project may use the template. If your organisation does have templates, seek ways to improve them.

55. Hone your toolkit

Rich pictures, sequence diagrams, business model canvas, running workshops.. and the other scores of tools and techniques in the BA toolkit. Practice them and then get them into your workplace. The more the merrier.

56. Encourage newbies

We were all new once. The profession is constantly refreshed with new and trainee BAs. Welcome people. Help them.

57. Don’t get stereotyped

Take on projects in areas that you haven’t done before so that you have experience and confidence in delivery in as wide a range of topics and disciplines as possible.

58. Avoid too much future-proofing

While it’s a very useful consideration some attempts at future proofing just don’t fit with the future when you get there. Unless it has wide application and has relatively no cost or impact to the project don’t overengineer it.

59. The devil is in the detail

Ask for detail and then spend time understanding complexities. If you don’t, annoying requirements will rear their ugly heads later, when you’re further down the road than is desirable.

60. Order your own tasks

It’s in our nature to do enjoyable things or things which are easy or small first and then rush others. Avoid this by monitoring deadlines and dependencies taking into account impacts from other people and their availability.

61. Decide what your goals are

Ask yourself where you want to be in 5 years and put a plan into place. It may be various certifications, it may be working on certain types of projects, with technologies or in specific locations. Work out the steps you need to get there.

62. Ask for help

No man is an island. There is no shame in asking for help whether about your career, with techniques or technical aspects.

63. Archive and catalogue

Don’t leave files, part finished documents, reference material and other artefacts as collateral damage of your work. Archive your documents, catalogue your information and generally make it easy for people to work out what are the most recent versions and what supports them.

64. Have a to-do list

Don’t risk forgetting important tasks for something as simple as keeping a list. Be organised.

65. Its ok to make mistakes

We are human and mistakes are inevitable. Know that you will make them and decide that dealing with them diligently and humbly will be appreciated and respected.

66. Estimate using metrics

If you’re asked to estimate for a piece of work, use quantitative methods as much as possible and share the information on which it is based.

67. Add a glossary

I have not seen a BA deliverable yet that hasn’t benefitted or would benefit from a glossary (either within the document or at project level). To determine what goes into it, consider your audience. You may need to add business terminology to give framework from IT readers and IT and project terminology for the business.

68. Vanilla is not the only flavour

Don’t forget about alternative flows. The abnormal activities are generally the pain points for most businesses. Overlook them at your peril.

69. Get your must-haves right

The MoSCoW rating is incredibly useful and the priority of requirements must be stated explicitly but it is only useful if you have ratified that a must-have requirement is absolutely necessary. Double check.

70. Chunk up your work and take breaks

By creating a series of much smaller tasks you maintain motivation as you complete activities and as a result have natural break points to re-energise you ready for the next task.

71. Speak up

If you see a possible method of improvement have the courage to vocalise it, respectfully and professionally.

72. Flesh out a plan but be flexible

Plan your assignments in a work-breakdown structure, so you can keep an eye on your own progress but don’t be too rigidly stuck to it that you can’t make the most of stakeholder time when they are available.

73. Do it now

If you get the choice between doing it now and doing it tomorrow; do it now. Procrastinating individual items adds up to lost time and missed deadlines.

74. Be motivated and committed

Volunteer enthusiastically, actively pursue end goals, deliver on your deadlines.

75. Find your USP

Maybe you’re a people person, good with data, can see the bigger picture, are an influencer, have specific technical expertise or domain knowledge, run killer workshops, are highly accurate….everyone has a unique selling point. Whatever it is, find it and use it.

76. Be an observer

Keep an eye on what your peers are doing. Look for cross-over and gaps between their work and yours.

77. Don’t cut corners

Guessing, not completing research fully, ignoring the quiet opposing viewpoint, not determining the full stakeholder group, failing to verify background information, removing valid approval stages are all ways to store up later problems. Don’t cut corners.

78. Run your own project

Is it possible to start a little business of your own? Doing this lets you really test your BA skills.

79. Display kindness and patience

When projects get pressurised this will make you stand out and be someone others want to have around.

80. Understand your Subject Matter Experts

Put yourself in their shoes. You’ve invited them to sit in a long meeting? Make it interesting, schedule breaks and bring biscuits.

81. Get your unfinished specs reviewed

Reduce your own risk of large rework by shipping parts of your document early and get feedback.

82. Take the initiative

Make suggestions. Improve your own team’s processes. Create bodies of knowledge. Organise socials Involve yourself.

83. Keep your requirements updated to the end

A change has been made at the eleventh hour, everyone knows about it, is there any need to take time-out to correct the documentation, especially when the pressure is on?….Yes. If you don’t, no-one will be sure of any of it in the future.

84. Take a step back

During meetings and workshops, take time to observe; interactions between people, gauge motivations. There is a lot more to be learned than comes in through the ears.

85. Control/Challenge scope

Consider scope constantly. It is the bread and butter of getting the optimal solution for the composite group of stakeholders.

86. Mock stuff up

User interfaces, documents, reports. Let your end users see and play with the final product at the design stage.

87. Minute your meetings

It doesn’t have to be War and Peace but make notes. Dictate, doodle or mindmap if it’s a more effective or efficient method for you.

88. Give people a “starter for 10”

People provide what you want more quickly if they’re not starting from scratch. If you have a template, provide it. If you want data, provide the table to be populated. If you want a quote, propose a sentence.

89. Learn standards

If there is a UML or ISO way of doing something then try to use it. It’s less ambiguous.

90. Use data analysis tools

Many Business Analyst roles include research in data. You can be more self-reliant if you are capable at manipulating it.

91. Use requirement ‘numbering’ for more than a unique reference

Use prefix letter, suffix letters and sub-numbering to store information about the source (stakeholder or actor), expected delivery method (various IT systems, manual processes, teams, department or companies) and dependencies on other requirements.

Eg, CS75-S.1 (CS = Customer Services, S = SQL, .1 = 1^st child requirement)

92. Don’t be vague

Make requirements specific. Eg the phrase “needs to be run regularly” should be “needs to be run twice a day, usually at 12pm and 5pm” and the phrase “other systems use it” should be “three Access databases, listed in Appendix C, link directly to the data”

93. Find your best packages

Find and get proficient with tools and application supporting BA work. Eg, for producing and tracking requirements, for producing diagrams, flows and other models, collaborating and conducting meetings, managing work, etc.

94. Change control your documents

Applying version control saves your readers’ time. Be specific about what’s changed in your version history and use function for highlighting changes.

95. Understand development basics

Gain some knowledge in the basics of development; processes, data and events, components and re-use, integration with other applications, design principles and constraints. Learning to write in a pseudo code style can help with that mentality.

96. Understand test basics

Gain some knowledge in the basics of testing; test condition design, what a tester needs from your documentation.

97. Conduct Stakeholder Analysis

Don’t leave this to your project manager, do your own. Know who your influencers are, your VIPs and any potential “troublemakers”.

98. Ask effective questions

Questions are the keys that unlock treasure troves of information. Closed questions are useful when you need to be specific and open questions are needed to allow free-flow of knowledge transfer. Learn how to make them effective and unbiased.

99. Get qualified

There are a number of qualifications tracks available in various jurisdictions. International Institute of Business Analysis, British Computer Society and International Requirements Engineering Board. For gaining knowledge in the fundamentals as well as sharpening practitioner skills it is invaluable and a résumé necessity.

Is Business Analysis an Art or a Science?

Written by Nadine Rochester on April 30, 2019. Posted in Articles. 1 Comment on Is Business Analysis an Art or a Science?

The role of a business analyst is complex, and involves studying an organisation,

learning about its systems, processes and business models, and both recommending and managing changes, with a view to solving problems. Often, a business analyst will not have a clearly fixed role or position, but might instead use information gained through business analyst or project manager training to involve themselves in a variety of different areas.

Crucially, business analysts need to possess both technical knowledge and creativity in order to achieve success, and it is this duality that sometimes causes confusion about precisely what the role entails and how it can be defined. In particular, there has been a considerable amount of debate about whether the discipline should be categorised as an art or a science, and this article makes the case that it is actually a combination of the two.

Business Analysis as a Science

To begin with, we must address the reasons why many people think of business analysis as a science. Effectively, this argument can be summarised by the fact that most business analysis training teaches BAs a series of processes and approaches, which can be deployed in the pursuit of solutions. There is usually an emphasis on repetition, with useful approaches being adopted time and time again, while outcomes are often tangibly measurable.

For example, as an article for Hawkins Point Partners points out, business analysis often involves gathering information in a very structured way. This might mean gaining clarity on what the business problem is, what it involves, what the constraints are, what the assumptions are, and the scope of the analysis project itself. A business analyst will then go through these same stages on almost any other business analysis project.

Moreover, business analysts will need to come up with ways to fix business problems, or make improvements to business processes and methodologies. These improvements will usually need to be demonstrable, as senior managers will want to see that objectives have been met, and that the BA is actually of value to them.

“Without the science (which brings process, techniques, templates and measurability), the business analysis field would never have become a recognised profession that commands the respect of fellow professionals,” a group of Business Analysts write in the BA Times. “Too often in the past Business Analysts were perceived as little more that note takers or junior Project Managers because we could not articulate the science and discipline.”

Business Analysis as an Art Form

On the other hand, some argue that business analysis is an art form. After all, a crucial part of the role is the use of information and other influences to actually create something new. It is also fair to say that standardised processes taught through business analysis training cannot always provide solutions. When obstacles are encountered, the onus is on the business analyst to find new and innovative ways of working.

“Without the art to recognise that every project is different and that it takes creative skill to successfully navigate all the people, personalities, and pitfalls that all projects face, the science of our techniques and processes would be almost useless,” the authors from the aforementioned BA Times article explain.

Another major part of the job involves bridging the gap between different parties, and balancing their needs, wants and expectations. This not only means that there is a requirement for excellent communication, but also that business analysts need to be able to consider different viewpoints, convey solutions in a clear and concise manner, and persuade stakeholders who are not immediately convinced by a proposal or recommendation.

This highlights the importance of soft skills, rather than relying solely on technical skills, theory and established concepts. Both written and verbal skills are vital, especially when it comes to creating a sense of urgency within an organisation or attempting to convince decision makers to act.

These aspects of the role are far less scientific or structured in nature than, for example, the repeated use of processes, or the clear focus on measurements. The art form of business analysis requires professionals to be able to think on their feet, learn lessons, and use past experiences to manage and deliver change.

The Final Word

The reason why there is so much confusion about whether to categorise business analysis as an art or science is because it is both things, simultaneously. The more scientific aspect of the role includes the structured approach to business problems, complete with the use of tools and processes. It is also one of the key reasons why the field of business analysis has gained credibility as a discipline of its own.

Nevertheless, there is also a creative or artistic side, which cannot be imparted through business analyst or project manager training alone. There is a requirement for creative or ‘outside the box’ thinking, so that alternative solutions are conceptualised and put into action. Ultimately, both the art and science aspects of the role are crucial, as business analysts cannot be successful without a combination of technical knowledge and creativity.

The Purpose, Scope, and Value of a Six Sigma Project

Written by Jane Thomson on March 26, 2019. Posted in Articles.

Six Sigma is a collection of tools and techniques that are focused on eliminating defects in a product, process or a service.

It is a disciplined and data-driven approach. It was developed by Motorola based on the fundamentals of quality management. The six sigma process includes many activities like measurement, improvement, and validation. It emphasizes the relationship between the performance of the product and the corrections that are required during the manufacturing of the product.
Six Sigma projects are used to measure the cost of improving the processes that are producing substandard products or services. Whether in service or manufacturing industries, these projects quantify the effect of process changes on delays or rework. The aim of each Six Sigma project is to produce statistically significant enhancements in a particular process. These projects use suitable tools within the Six Sigma approach to producing financial benefit and improved performance of processes or services.

The purpose of a Six Sigma Project:

As the cost of material is rising and the competition is increasing day-by-day, organizations look for techniques that are capable of increasing the efficiency of their projects. Six Sigma projects focus on improving the efficiency of the organizations. By implementing the Six Sigma methodology, an organization can enhance the efficiency of their products, processes or services through identification and resolution of product or defects that might affect the organization and minimize the variation within the process. Every Six Sigma project follows a defined series of steps which include specific targets for improvement. Few examples include:
● Reduction in the process cycle time
● Reduction of scrap generated by a process
● Increasing customer satisfaction
● Reduction in the number of factory defects
● Reduction or elimination of costly reworks

The scope of a Six Sigma Project:

Project scope is a part of the Define phase in the DMAIC process and is included in the Project Charter. A project scope describes the limitations of a project. It keeps the team in alignment, on purpose, contained, focused, and motivated. The project scope might include:

● Beginning time and end time of the project
● Duration of the project
● Process boundaries of the project i.e what is within the scope and what is outside the scope.
● Sub-processes involved in the project
● Product lines of the project
● Locations involving the divisions, states, territories, and countries.

The most important component of the project scope is addressing the beginning and the end of the project. This is often outlined in the SIPOC diagram.

Importance of defining the scope of a project:

● The project scope explains what the project involves so that all stakeholders can understand what is involved
● It provides a roadmap to the managers in order to assign various tasks and schedule work and budget appropriately
● It helps the team members to focus on common objectives
● It prevents complex projects from extending beyond the fixed vision

How to define the scope of the project:

The criteria under which the scope of the project is defined is:

1. Deliverables: The end project delivered to the user and the deliverables generated by the project itself. These are called internal and external deliverables.
2. Data and functionality: Licensing agreements, payment processes, and customer management.
3. Technical structure: The focus of the project on infrastructure.

The value of a Six Sigma Project:

The value of a six sigma project is defined as the business case of a project. It is a document that uses the problem and goal statements of a project and converts them into a business value statement. There are five different cases:

● Strategic case – It is a compelling case for change that suits the strategic goals of the organization.
● Economic case – It is the solution that represents the best value for the problem.
● Commercial case – It is the recommended solution that is attractive to the market and can be obtained using suitable terms so it is commercially feasible.
● Financial case – It is the proposed financial investment that is affordable.
● Management case – It is the input required from all individuals involved in the project.

The steps to write a business case for a project:

The steps to write a business case are as follows:

1. Research the competition, market and any other alternatives for a project.
2. Compare it with the other approaches and finalize it.
3. Compile the final data and
4. Document

In addition to the above metrics, six sigma projects have seven different responsibilities. These are:

1. Leadership: The team defines the goals and the objectives in a six sigma process.
2. Sponsors: They are the individuals who understand what six sigma is and are dedicated to its successful implementation. They solve problems which might occur during the process.
3. Implementation Leader: These are the individuals who are responsible for supervising the team effort. They support the leadership team by ensuring the timely completion of the processes.
4. Coach: An individual who is an expert or consultant in Six Sigma who sets a schedule for the team and resolves any conflicts among them.
5. Team Leader: The person responsible for managing the team. They also act as a medium of communication between the sponsor and the members of the team.
6. Team Member: The individuals who work on a six sigma project. They have specific roles and work collectively with other team members.
7. Process Owner: The person who is responsible for the management and monitoring of various processes after the team has completed their work.

Six Sigma methodology focuses on a better understanding of what the customer requirements are and how the quality of the products delivered can be improved. It concentrates on waste reduction and cost reduction.

Top Tools for Successful Business Analysts

Written by Katie Cubitt on March 13, 2019. Posted in Articles.

In order to be a great business analyst (BA):

Knowledge of the business, understanding the technical aspects and a capability in the tools of the trade are all key to ensuring high-quality software is delivered on time and as per spec.

A complicated role, BAs within the ICT sector decode the client’s business requirements into carefully considered technical specifications that software engineers use to develop what the client is asking for.

Nosipho Rakoma of BBD, a BA at a leading software development firm, explains that “many of the clients I’ve worked with have their own preferred tools. The trick is to immerse yourself in the client’s operations and be flexible in your knowledge and approach of the tools BAs can use”. She adds that although BBD favours an Agile mindset, project teams are encouraged to work in a manner and with the tools that are most suited to each client environment.

Here is a list of the top five tools BBD BAs love to use:

1. Jira and Confluence

Jira and Confluence form part of the Atlassian stack and are powerful collaboration software programs that allow for an open and shared work space that helps you manage the details within a project without losing sight of the big picture. They also enable you to create a single source of truth for your software documentation, while helping ensure easy communication between BAs, test analysts and the software engineers.

Although originally designed for Agile development teams, this update-as-you-go software is useful for BAs no matter their team’s methodologies or mindset. Rakoma believes that with the world looking to Agile, aspiring and experienced BAs need to be comfortable with these types of tools.

2. Microsoft Visio

As diagrams depicting project dependencies and schedules are an important element in a BA’s project manager or scrum master role, the Microsoft Visio diagramming tool is excellent for remaining on top of all of the moving parts within a project.

For everything from workflows to process maps and network diagrams, this powerful visualisation tool helps display and drill into the project elements. This is beneficial for BAs because it helps maintain a clear overall picture, and aids in easier execution and communication with both technical and non-technical team members.

As part of Microsoft Office, Visio shares functionality with Excel, Access and Word.

3. Enterprise Architect (EA)

EA is a full cycle online modelling tool with built-in requirement management capabilities. Made for business and IT systems, it allows real-time, embedded development and the all-important version control. The beauty of this tool is that for distributed teams, where not every member sits in the same office, managing tasks, responsibilities and dependencies doesn’t become an issue.

4. HP QC

The HP Quality Center is quality management software boasting requirement and test management, and business process testing for IT environments. HP QC is a component of the HP application lifecycle management software solution set and is good for day-to-day tasks. Although face-to-face time is important in development teams, some BAs find this tool especially helpful because it can often help save time so that your meetings are only about what’s most necessary (you know, for all those times the meeting could have been an email).

5. Video conferencing

Because you don’t have to be in the same location to deliver, and often aren’t, video conferencing tools such as Zoom, Appear.In and Rocket.Chat can be exceptionally helpful for project delivery teams. Because BBD has a global footprint, with teams sitting in different countries, video conferencing makes daily stand-ups and team meetings that much easier. Additional tools worth a mention include Trello and Excel.

Rakoma concludes that change is hard, and changing your toolset is especially so. But there is truth to the adage that if you’re not changing then you’re not growing because growth in the ICT sector means more opportunities.