by John Parker | Mar 7, 2014 | Business Analysis, Collaboration, Uncategorized |
In one of my recent blog articles, Risk Management: Business Analysis is a Huge Risk for Most Organizations, I stated that business analysis is at a dangerously low level of maturity for most organizations as evidenced by Standish Group Research, which analyzes project performance. Standish Group Research shows that the top five reasons for failed or challenged projects are: Lack of user involvement Lack of transparency Poor or incomplete requirements Changing requirements Lack of business alignment Now, examine these problems carefully; all of them are related to poor business analysis. Looking at this and other research, I firmly believe that poor business analysis is the number one cause of failed and challenged projects. According to the Business Analysis Body of Knowledge (BABOK), business analysis involves much more than just writing solution requirements. However, in many organizations, BAs only write solution requirements and do not perform other key activities specified in BABOK. For example, few business analysts are actually involved in Enterprise Analysis and Solution Assessment and Validation which are two key knowledge areas specified in the BABOK. Many people think that Requirements Analysis and business analysis are one in the same. Requirements Analysis is only one of the six knowledge areas in BABOK. It’s important to stress that there is much more to business analysis than just writing solution requirements. Many confuse requirements engineering and business analysis, thinking they are one in the same; however, they are not. Understanding the differences is key for successful IT projects. Requirements engineering, although helpful, is certainly not the key for success on business IT projects. Requirements engineering might address problems 3 and...
by George Casey | Oct 22, 2013 | Business Analysis, Collaboration, Uncategorized |
There is no “I” in team, and research shows there hasn’t been one for decades. Teamwork and the ability to succeed in a team environment – for the betterment of the team – are not new concepts. The skillset continues to be called on by managers and business leaders, and through the years, it has become a fundamental value of employees across all industries. Recognizing how important teamwork is to collaboration and communication, especially in requirements development, we revisit John Maxwell’s resource from 2006, the 17 Essential Qualities of a Team Player. In it, Maxwell asserts that teams win when they have good players, and on collaborative teams, each member has a talent that strengthens the whole team. Here, we revisit those 17 characteristics, recognizing that their importance never goes out of style. 1. Adaptable. Good team members are able to work with a variety of groups, from stakeholders to developers. They are flexible, open to different mindsets, and able to transfer their knowledge to new groups and endeavors. 2. Collaborative. Good team members see others as co-workers, not as competitors. They focus on the group and celebrate collective victories. 3. Committed. Teams are successful when they have members who are dedicated and believe in the value of their work. Good team members increase their level of commitment when they face a challenging task: The more difficult the problem, the less likely they are to give up. 4. Communicative. Communication is essential to team-building. Good team members communicate candidly and directly. When a problem arises, they resolve it promptly. 5. Competent. Good team members make a commitment to excellent...
by George Casey | Mar 11, 2013 | Business Analysis, Collaboration, Uncategorized |
In order to form a more perfect software solution, establish collaboration, insure team tranquility, provide for desired outcomes, promote success, and secure the blessings of excellent requirements management, software customers do ordain to have certain rights – and responsibilities. To have true software success, requirements management expert Karl Wiegers addresses the customer-development relationship with a Requirements Bill of Rights – and corresponding Bill of Responsibilities – for Software Customers. Software Customers Requirements Bill of Rights Right #1: To expect analysts to speak your language. You shouldn’t have to wade through indecipherable computer jargon when talking with a Business Analyst (BA). Right #2: To have analysts learn about your business and objectives. By interacting with you while eliciting requirements. The BA should be able to understand your business tasks and how the product fits into your world. Right #3: To expect analysts to write a specification. The soſtware requirements specification (SRS) should be organized and written in a way that you can understand. Right #4: To receive explanations of requirements work products. Terms like “user-friendly” or “robust” or “efficient” are too vague and subjective to help the developers. Instead, the BA should inquire about specific characteristics that mean user-friendly, robust, or efficient to you. Right #8: To be given opportunities to adjust requirements for reuse. The BA should give you the option of modifying your requirements if needed so the developers can reuse existing software to save time and money. Right #9: To receive good-faith estimates of the costs of changes. Developers should present realistic estimates of impacts, costs, and trade-offs. They must not inflate the estimated cost of a change...
by John Parker | Jul 12, 2012 | Business Analysis, Collaboration, Uncategorized |
This is the fourth article in a series of blogs discussing individually each of the 12 Keys For Successful Enterprise Projects, published in my blog on Tuesday, June 26, 2012. Today, for most organizations, the development lifecycle is a black hole. Requirements are developed in a list, usually captured in either Word or Excel. From that point forward until a new system is implemented, requirement stakeholders are often left in the dark. Usually, stakeholders are not even provided a copy of the business case, the project vision, or the project objectives as part of a validation process. How can they provide meaningful input without this information? After the requirements phase is completed, the information void gets worse. Except for possibly being able to view the project plan and maybe receiving occasional status reports often presented only to the project owner, stakeholders frequently have no idea about project status at any point in time. This results in stakeholders asking themselves “Are we 50% complete? 75%?” There is really no way to gauge real status if the project team goes off to the corner to do their work and the client is left out of the development loop. Clearly, real transparency is key. So, the first benefit to project transparency is being able to accurately understand where you are in the development cycle. But transparency brings other more striking benefits. If you can see what tasks the team is working on, review the latest internal project plan, download the source code, read the latest technical documents, etc., participate in testing, and the like, don’t you think the team is more likely...
by John Parker | Jun 26, 2012 | Business Analysis, Collaboration, Uncategorized |
In most organizations, the costs associated with poor processes, poor communications, and unnecessary development due to poor requirements is staggeringly high. Many of these problems can be traced back to ineffective business analysis practices. A number of studies have shown that 40% or more of defects in a typical software development project stem from inaccurate, unclear, or incomplete requirements. These poor requirements not only cause costly rework but also result in the late delivery of projects, as well as delays in obtaining planned cost savings or additional revenues. Not only do you lose the revenue or cost savings that would have been generated in that time, you also lose the opportunity to implement other benefits your team could have delivered for other needed projects in that period. Poor business analysis also leads to poor estimation because critical elements of the problem are overlooked or the solution ends up being more complex than it really needs to be. Poor business analysis skills also mean that it’s less likely that you will be able to capture the value projects were intended to deliver in the first place. Without effective enterprise analysis, project requirements can devolve into a wish list from various stakeholders. Yes, your stakeholders may individually be happy if they get what they want but there’s no guarantee that what they want is what the organization needs. Uncoordinated changes made without analysis can make one unit’s work easier and another group’s harder. It’s the Business Analyst’s job to make sure that the bigger picture is understood and that requirements are in line with that larger objective. The founders of Enfocus...
by John Parker | Jun 18, 2012 | Business Analysis, Collaboration, Uncategorized |
We are currently starting a research project on best practices to engage stakeholders on enterprise projects. We are just getting started with our research, but we have found that many organizations struggle in this area. Agile teams seem to do better than waterfall teams when they have a good product owner. However, they also struggle for a variety of reasons: Often a product owner cannot speak for all stakeholders; the product owner represents one view and is often biased towards their own view. The product owner is not a true user of the software and often does not understand how users perform their work. The product owner is not located with the team and communication does not go as well as planned. The product owner has many other responsibilities and does not have the time to devote to the project. Some organizations have used multiple people to play the role of the product owner resulting in confusion for the team. Below is a list of 8 best practices that we have found so far in our research project for stakeholder engagement. 1. Treat Stakeholder as Partners All parties involved on the project will achieve a better result if they work together and cooperate as partners. Excellent software products are the result of a well-executed design based on excellent requirements. High-quality requirements result from effective communication and collaboration between developers and customers – a partnership. Too often, the relationship between development and customers becomes adversarial. Managers who override user-supplied requirements to suit their own agenda can also generate friction. No one benefits in these situations. A collaborative effort can work...
