by John Parker | Feb 14, 2014 | Business Analysis, Project Management, Uncategorized |
Delivering a project “on-time and on-budget” is no longer an adequate measure of project success. In today’s environment, the key question should be: “Did the project deliver value to the business?” For example, a project could be delivered on time and on budget, but does not guarantee: Benefits outlined in business case were achieved User adoption Expected ROI was achieved A satisfied customer The solution addresses the customer need Sales were in line with forecasts There will be market demand for the product As a project manager, you may think that delivering business results isn’t your concern and that it is the customer’s problem to solve. However in today’s environment, project managers are expected to partner with the customer, understand the business drivers, and ensure that the project delivers the business results that were specified in the business case. That is how many organizations are beginning to view project success. Delivering business value can be a tall order. Delivering business value requires gaining an understanding of the business drivers: the problem or opportunity that precipitated the project and defining a clear set of business objectives to address the problem. Measuring business value is best done through defining Key Performance Indicators (KPIs) and measuring actual performance using the KPIs. Key Performance Indicators are quantifiable measurements that are agreed to by stakeholders to reflect the critical success factors of an organization. KPIs are: Established by the customer at the beginning of the project and listed in order of priority. Directly related to and supported by business goals and objectives. The basis for critical decision-making throughout the project. The basis for acceptance...
by George Casey | Jan 20, 2014 | Uncategorized |
In evaluating business performance, business analysts, requirements management experts, and business leaders are all looking at the ROI. When bringing in consultants for new projects and processes, the focus on ROI stays in place. As clients, businesses are seeking tangible improvements in ROI. In return, consultants are becoming more and more prepared to demonstrate their impact. Both clients and consultants want to see the effect on the bottom line – before they sign on the dotted line. Jack Phillips explores this topic in “The Consultant’s Scorecard — Tracking Results and Bottom-Line Impact of Consulting Projects.” He underscores the point that not tracking ROI can be hazardous for both businesses and hired consultants: Wasted resources – When not focusing on the results that count, too much money can be wasted on interventions that are not defined and measured. Burned-up staff time – Phillips reminds us that consultants often have to consume a significant amount of staff time to provide them information and bring them up to speed. Negative effect on staff morale – This wasting of employees’ time affects morale. Because consultants report back to management, employees don’t see their contributions and only seem consultants as taking up time and creating work. Poor advice – When not tracking to ROI, consultants can give poor advice that results in reduced profits and increased expenses. Damaged careers – Supporting the wrong consultants can be detrimental to a manager’s career. With this much at stake, it’s imperative to have a solid ROI assessment in place that clarifies That various stakeholder groups can respond to the consultant at timeframes throughout the project Whether specified...
by Enfocus Solutions | Oct 28, 2013 | Business Analysis, Uncategorized |
Requirements repositories are a method of storing requirements, encompassing those under development, in review, and approved. They are an efficient means of gathering, managing, and leveraging data across the enterprise – including business, stakeholder, solution, transition, project, and quality requirements – along with supporting documentation, such as whiteboard sketches, word processing documents, diagrams, and visual models. Capturing all that information in itself can be difficult. Capturing the information in a repository that is accessible, meaningful, searchable, and sharable presents further challenges. Keeping in mind these three best practices for knowledge management can help. Usability Repositories are only valuable if they’re used. To promote use, the repository has to be part of the daily life of the work environment. It has to function with the overall enterprise architecture, and integrate with other technologies in use, such as Outlook, project management systems, and SharePoint. Also, people have to be able and willing to access it regularly. They have to be motivated to populate a repository. On the receiving end, it has to be easier for them to access the repository for information than to walk across the hall and ask for it. Use of the repository has to be bought into, encouraged, and mandated from the top down and the bottom up. Context The repository also has to be relevant. Requirements are valuable only when they are connected and in context. Imagine the Internet without Google: It’s just a massive amount of information with no context around it. Repositories must provide an easy way for people to search and access the information that has meaning to them. Many businesses seek to...
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 Karl Wiegers | Jul 2, 2013 | Business Analysis, Uncategorized |
Written by Karl Wiegers and Joy Beatty Reuse is an eternal grail for those seeking increased software productivity. People think most often in terms of code reuse, but many other software project components also have reuse potential. Reusing requirements can increase productivity, improve quality, and lead to greater consistency between related systems. Reuse is not free, though. It presents its own risks, both with respect to reusing existing items and to creating items with good reuse potential. It will likely take more time and effort to create high-quality reusable requirements than to write requirements you intend to use only on the current project. In this article, adapted from our new book Software Requirements, 3rd Edition (Microsoft Press, 2013), we describe some of the approaches an organization should consider taking to maximize the reuse potential of its requirements. Just because a requirement exists doesn’t mean it’s reusable in its present form. It could be specific to a particular project. It might be written at too high a level because the BA could safely assume certain knowledge on the part of the development team or because some details were communicated only verbally. A requirement could be lacking information about how possible exceptions should be handled. You might have to tune up the original requirements to increase their value to future BAs. Well-written requirements lend themselves to reuse. The steps you take to make requirements more reusable also increases their value to the project for which you originally write them; it simply makes them better requirements. Reusers need to know about dependencies the requirement has on others, as well as other requirements...
