Articles Archives - Page 376 of 417 - Business Analyst Articles, Webinars, Templates, Jobs

BA Opportunities in the New Economy

Written by Marcos Ferrer on August 25, 2009. Posted in Articles. 1 Comment on BA Opportunities in the New Economy

For the last six months, I have been working in a very different kind of environment, on a very different kind of opportunity. It made me realize that there are career paths for BA skills that are not obvious (and potentially quite lucrative), so this month I share a few.

First of all, I am having the time of my life. My new venture is an entrepreneurial opportunity in the bowling and family entertainment businesses (think family fun, arcades, boardwalks, bowling centers).

In this process, in just six months, I have had to:

Understand and communicate requirements to integrate different vendor technologies (coin and credit card acceptors with bowling accounting control systems). Integration was implemented even before I knew, just based on the essential (not detail) requirements I developed, in less than three months (instead of over three years with 300 meetings).
Design and implement a nationwide customer database using online service providers.
Build a new product cost model (miniature bowling) in preparation for negotiating with suppliers and manufacturers.
Build a new business model identifying resources and feasibility plans for marketing the new product.
Facilitate industry product SMEs to help them identify improved, lower cost, higher quality (i.e., way more competitive) approaches to miniature bowling.
Write magazine articles describing the new business, its mission, and its advantages to potential customers.
Draw business organizational models involving seven different vendors, and their contributions to the business overall.
Learn a new system, the choices it offers and the choices it is missing.
Develop Return on Investment models for the new business and for the customers of the new business who would buy the product.
Change the business model twice (each time with the support and enthusiasm of the principals).
Negotiate with suppliers and manufacturers (and trademark attorneys!) based on detailed, mutual understanding of the requirements, leading to creative solutions and agreements.
Make decisions, not just recommendations.
Visit customer locations to understand requirements (what a change from the federal government people, who are reluctant for anyone to talk to their stakeholders, who are universally unhappy – as if ignoring the unhappiness would fix it).
Implement web based on line banking and accounting, and processes for those with a need to know.
Brainstorm product names that communicate the essence of the product (i.e., the essence of the requirements that have been assembled.
Outsource other business processes, with the goal of creating an extremely lean organization, including marketing campaigns, demographics analysis, payroll.
Start a Use Case Model for bowling and family entertainment businesses (this is an intellectual property that could eventually be published as an industry reference, making me an instant expert).

So, what I have learned from this is that BA skills (see BABOK) lead to numerous possible job titles/positions, quite different from the usual IT production of lengthy, unread requirements documents. These jobs, which I encourage you to consider, include:

Product Developer
Product Manager
Entrepreneur
Small Business Web Outsourcing consultant
Small Business consultant, period
CEO staff
CEO
Writer
Industry Guru (modeler)
What else in inherent in the above that I didn’t think of? Oh – I could get the raise of MY LIFE, as current plans (conservative) indicate that profits for the two main partners (including myself) could reach $1.67M by year three.

Anyone who wants to explore career alternatives can contact me anytime.

Don’t forget to post your comments below

Marcos Ferrer, CBAP has over 20 years experience in the practice of business analysis and the application of Information Technology for process improvement. While still a student at the University of Chicago, he developed a consulting practice with local property management and accounting firms. Following graduation in 1983, Mr. Ferrer joined IBM in Chicago, where he worked on requirements and systems implementations in diverse industries. In 1990, Mr. Ferrer became an independent consultant, again working with a variety of clients in the family entertainment industry and then for 10 years at the U.S. Department of Labor, converting legacy COBOL systems into real time client server systems. His recent projects include working requirements for the Veteran’s Administration, introducing BA practices at the Washington Suburban Sanitary Commission, and creating bowling industry models for NRG Bowl LLC. In November 2006, Marcos Ferrer became one of the first 18 CBAPs certified by the IIBA. He has served as an elected member of the DC-Metro chapter of the IIBA, most recently as President, and assisted in the writing of the BOK 2.0 test. He can be reached at [email protected]!

Getting that Non-Contributing Team Member to Shape Up!

Written by Phil Ventresca on August 25, 2009. Posted in Articles. 1 Comment on Getting that Non-Contributing Team Member to Shape Up!

Ever asked yourself: “What are the elements that go into building a high performance team?” They are many: committed competent individuals; clear goals and objectives; well defined roles and responsibilities; excellent communication, etc. But what happens when one member of the team is less conscientious than the rest? How do you effectively deal with this individual without harming group productivity and morale?

This is an interesting and challenging question that plagues many teams in a variety of organizations. The reality is that by not responding and allowing this person to perpetuate their lackadaisical behavior, you will do more damage to the team’s productivity and morale than if you had addressed the problem head on. Keep in mind that your team wants to succeed as individuals as well as collectively. A weak link will demoralize the collective culture and allow for rapid deterioration within the spirit of the team.

I recommend an aggressive, yet compassionate, approach to the resolution of the lackadaisical behavior. Try some of the following suggestions:

Promote a performance measurement campaign that allows for visibility around collective expectations. This campaign should set measurable standards for work to be done. The core of this system can be built on schedules, work break down structures, and work packages on individual assignments.
Speak openly in the team environment about each other’s roles. Ensure that all individuals on the team understand their goals, mission and individual responsibilities. These conversations should be collaborative and constructive. Create an environment that fosters individual and collective accountability.
Provide team members with a structure around the charter, goals, values and mission for the group. Each team meeting should include reflection upon the norms created by the aforementioned items.
Remember, building an effective performance team takes time, and there may be instances along this path that cause friction for one or more members. Ensure that an open channel of communication, both formal and informal, is maintained among team members at all times.

If none of the above recommendations work to enhance the performance of this individual, more assertive and individual action must be taken. Begin an individual coaching and measurement process, which includes specific performance expectations. Meet with the team member and let him/her know about the problems their behavior is causing, and the potential negative impacts this will have on the team, project and organization.

Agree on coaching goals in writing, and set dates for periodic performance reviews. Follow up aggressively to ensure the team member’s training/coaching needs are met in a proactive manner. If the individual does not respond to the personal attention, removal from the team will be necessary. Failure to do so will promote dissent within the team, and ultimately hurt the overall performance.

Throughout the experience, communication is critical. Do not allow speculation on performance issues. Deal with the situation directly, and although the team does not need to be privy to the details of any coaching or performance improvement techniques you may be employing, make sure they are aware that you, as a team leader, have addressed the situation and are working aggressively towards a resolution. Although these types of situations are difficult, a team leader must rise to the occasion in order to preserve the integrity of the team and maintain morale.

Don’t forget to leave your comments below

Phil Ventresca is Founder, CEO and President of Advanced Management Services, Inc. (AMS), a full service management consultancy servicing an international client base. Since founding AMS nearly two decades ago Phil has lead the organization to becoming an internationally recognized provider of Consulting, Training and Assessment services. AMS’s client base is comprised of Fortune 100/500 companies, medium-sized businesses and Government agencies that Phil has personally assisted in the creation of organizational and performance based solutions.

Capturing Requirements with Use Cases

Written by Todd Wyder on August 25, 2009. Posted in Articles. 1 Comment on Capturing Requirements with Use Cases

Use cases are becoming more mainstream as a method for capturing requirements, as evidenced by the endorsement of big companies and methodologists such as Booch, Rumbaugh, and Coad. One benefit of use cases is that each one encapsulates a set of requirements. This encapsulation lets you easily manage and track the use cases individually and provides a better alternative to prose requirements.

There is more to effectively using use cases than just capturing them and putting them into diagrams. As you implement use cases, you need to validate them, determine their size, and establish a plan for implementation. Then, you need to incorporate the use cases into your system design and turn them into code and documentation. Throughout this process, you must also be aware of the status of each use case. This article will discuss ways to do all these things.

Validating Requirements with Use Cases

Once you’ve captured a use case, you need to confirm whether it accurately describes the system and is truly needed by the system’s users. Sometimes, in the course of development, you realize some of the requirements you’ve created are unnecessary or peripheral to the main purpose of the system. You must identify these as soon as possible, so you can work on the functionality that is the most valuable to the customer. But how do you determine which use cases are most important to your users? You use a method called Quality Function Deployment (QFD).

QFD helps you weigh use cases to determine which ones are important and which can be discarded. To use QFD, users representing each group in the actor catalog are given a list of the abstract use cases and $100 in virtual cash to spend on the ones they think are the most important. The amounts are then tallied to determine which features are the most desired.

When using QFD, it’s important to keep one caveat in mind: make sure you include on the list all the obvious features the users will expect in the system, because it’s very likely these features will not come up while you’re gathering use cases. For example, in the banking program, users would obviously require a “transfer funds” use case. However, because they expect this feature to exist, they might not consider it important and not allocate funds for it. It’s important to allow for this and include the basic functions of the system into the QFD.

Sizing

Because use cases describe functionality from the user’s point of view, they can be directly converted to function points. Assigning function points to use cases helps us understand how large a use case is and the associated effort needed to produce it.

We can use this knowledge in iterative development to divide the iterations into roughly equal sizes and determine earned value. Some companies use earned value to recognize revenue. You can do this by dividing the estimated cost of a program by the number of function points, which yields a cost per function point. Each use case then becomes part of the executable. Multiply the number of function points associated with each use case by the cost per function point. The result is the amount of revenue recognized. You can use this same technique for project tracking by using the number of function points delivered to determine the progress on the project.

Iterative Development

Determining the implementation order of requirements involves several conflicting factors: the needs of the customer, the needs of the development team, and the needs of management. The customers would like to see the parts of the program they want implemented first. The development team needs to work on the most complex parts of the program first, so it can move from high complexity to low complexity. Management would like to work on the parts with the highest risk, so they can move from high risk to low risk.

So, how do you balance all three concerns? The customer’s needs are known through QFD. If you deliver the iterations based on the QFD scores, you ensure customer satisfaction. But to also satisfy the needs of the development team and management, it’s best to rank each use case for complexity and risk as well. Here’s one way to do this: Rank complexity on a scale from one to five, with one being very simple, four being very complex, and five unknown. Rank risk similarly, with one being marginal, four being high risk, and five unknown. Once you’ve rated all the use cases, multiply complexity, risk, and the QFD percentage to get a weighted value that takes into account customer satisfaction, complexity, and risk.

Design

Use cases can help you create your system design and also serve as the foundation of design reviews. Use cases can be readily converted to object, interaction, and event diagrams and used as a basis for CRC cards. In a design review, use cases force designers to show how each use case is enabled by the design, and which elements of the design are not part of any use case. This ensures all requirements are implemented and no unnecessary work is done.

Testing and Documentation

Use cases are the backbone of testing and documentation. If the use cases are clearly stated and testable, they form the basic system test plan. They are also well suited for acceptance testing, in which users test all use cases on the system and approve the system’s performance of each one. Because use cases represent the user’s perspective, they can form the initial user manual, online documentation, or help file. Some divisions of Microsoft use a similar technique; they write the user manual first and it becomes the specification for the program.

Use Case Tracking

To make sure you deliver what the customer has asked for, you need to know the status of each use case. Knowing where each use case is within the software life cycle is valuable for managing the project and determining status. You can accomplish this goal by assigning each use case a Work Breakdown Structure (WBS) in the project plan. Then, as you track the project, you also track each use case. This also yields a method for determining WBSs.

As your project progresses, you need to manage and control your use cases. A repository makes this possible. One method is to keep the data in a groupware database product such as Lotus Notes and include the following information on each use case:

A short descriptive name of the use case in the form of an action verb and noun, such as “export to spreadsheet”
A detailed description of the action the use case performs
The preconditions: other activities that must take place before this use case executes
The post conditions: the actions that will happen to the use case after it executes
The exceptions: what happens if the use case fails
The pattern name from Coad, Gamma, and so on
The Work Breakdown Structure (WBS)
The number of function points required
The location of the design files for the use case
The location of code files for the use case
The modifications made to the system, the date the modifications were made, and the name of the person who made them.

Use cases are a valuable tool for capturing and managing requirements. You can use them in all facets of the software development life cycle. As you move throughout the different phases of your next project, think of how use cases could be involved and how you would manage them. If you manage and track use cases well, you’ll be able to use them to their fullest.

Don’t forget to leave your comments below

Todd Wyder is Vice-President Product Management and Development at COE Truman Technologies, Inc., a 25 year old information firm that provides software products and professional services to a wide range of industries. Todd is a goal-oriented executive with experience in planning, developing and implementing cutting-edge information solutions to address business opportunities

The Business Analysis Center of Excellence; A Vital Strategic Asset

Written by Kathleen B. Hass, PMP on August 18, 2009. Posted in Articles.

The Business Climate

In the twenty-first century, business processes have become more complex; i.e., more interconnected, interdependent, and interrelated than ever before. Businesses today are rejecting traditional organizational structures to create complex communities comprised of alliances with strategic suppliers, outsourcing vendors, networks of customers, and partnerships with key political groups, regulatory entities, and even competitors. Through these alliances, organizations are addressing the pressures of unprecedented change, global competition, time-to-market compression, rapidly changing technologies, and increasing complexity at every turn. Since business systems are significantly more complex than ever, projects that implement new business systems are also more complex. To reap the rewards of significant, large-scale business transformation initiatives, designed to not only keep organizations in the game but make them a major player, we must be able to manage complex business transformation projects.

Why Now?

Centers of excellence are emerging as a vital strategic asset to serve as the primary vehicle for managing complex change initiatives. A center of excellence is a team of people that is established to promote collaboration and the application of best practices (Geiger, Jonathan G. Intelligent Solutions: Establishing a Center of Excellence. BIReview: March 20, 2007. http://www.bireview.com/article.cfm?articleid=222). Centers of excellence exist to bring about an enterprise focus to many business issues, e.g., data integration, project management, enterprise architecture, business and IT optimization, and enterprise-wide access to information. The concept of centers of excellence (COE) is quickly maturing in twenty-first century organizations because of the need to collaboratively determine solutions to complex business issues. Project management offices (PMO), a type of COE, proliferated in the 1990s as a centralized approach to managing projects, in response to the challenges associated with complex projects in an environment with low levels of project management maturity and governance. Industry leaders are effectively using various types of COEs, and BACOEs are among them.

A Slippery Slope

We are fortunate to have learned from the implementations of PMOs. The Project Management Institute’s research program studied PMOs in an attempt to publish a PMO standard. However, they were unable to do so, because they found out that there is no real standard practice for PMOs (Hobbs, 2007 PMI PMO Research Report). Here is what they discovered:

PMOs have been prevalent since the mid 1990s; yet, most have been in existence for two years or less
Only 50% of PMOs are seen as relevant and adding value
Most operate autonomously from other PMOs
Most organizations have trouble finding the right “fit” culturally and politically
Closure and restructuring happens frequently
Implementation time takes six months to two years; yet, there is a short time to demonstrate value before being closed or restructured; many are closed or restructured before they are completely implemented
There is a wide variability in the percentage of projects within the mandate of the PMO
Either all or none of the project managers are located within the PMO
Most PMOs have a very small staff due to the key issue of cost

Conclusions: it is a difficult endeavor to establish a center of excellence that is accepted and supported by the organization. A considerable amount of due diligence is needed to make sure the new center is successful.

It’s About Value

For a BACOE to be viewed as adding value, one of the critical functions is benefits management, a continuous process of identifying new opportunities, envisioning results, implementing, checking intermediate results, and dynamically adjusting the path leading from investments to business results. Therefore, the role of the high-value BACOE is multidimensional, including: (1) provide thought leadership for all initiatives to confirm that the organization’s business analysis standards are maintained and adhered to, (2) conduct feasibility studies and prepare business cases for proposed new projects, (3) participate in all strategic initiatives by providing expert business analysis resources, and (4) conduct benefits management to ensure strategic change initiatives provide the value that was expected. The BACOE is staffed with business/technology experts, who can act as a central point of contact to facilitate collaboration among the lines of business and the IT groups.

Implementation Considerations

Integration

Although the BACOE is by definition business focused, it is of paramount importance for successful centers to operate in an environment where business operations and IT are aligned and in synch. In addition, the disciplines of project management, software design and development, and business analysis must be integrated. Therefore, to achieve a balanced perspective, it is important to involve business operations, IT, PMO representatives and project managers, and representatives from the project governance group in the design of the BACOE. Indeed, your organization may already have one or more centers of excellence. If that is the case, consideration should be made to combining them into one centralized center focused on program and project excellence. The goal is for a cross-functional team of experts (business visionary, technology expert, project manager and business analyst) to address the full solution life cycle from business case development to continuous improvement and support of the solution for all major projects.

Mission

Understanding the business drivers behind establishing the BACOE is of paramount importance. The motive behind establishing the center must be unambiguous, since it will serve as the foundation to establish the purpose, objectives, scope, and functions of the center. The desire to set up a BACOE might have originated in IT, because of the number of strategic, mission-critical IT projects impacting the whole organization, or in a particular business area that is experiencing a significant level of change. Whatever the genesis, strive to place the center so that it serves the entire enterprise, not just IT or a particular business area.

Placement

One of the biggest challenges for the BACOE is to bridge the gap that divides business and IT. To do so, the BACOE must deliver multidimensional services to the many diverse groups. Regardless of whether there is one COE, or several more narrowly focused models, the BACOE organization should be centralized. “Organizations with centralized COEs have better consistency and coordination, leading directly to less duplication of effort. These organizations configure and develop their IT systems by business processes rather than by business unit, leading to more efficient and more streamlined systems operations” (2006 USAG/SAP Best Practices Survey: Centers of Excellence: Optimize Your Business and IT Value. SAP America Inc. February 16, 2007). Best-in-class BACOEs evaluate the impact of proposed changes on all areas of the business and effectively allocate resources and support services according to business priorities.

Positioning is equated with authority in organizational structures; the higher the placement, the more autonomy, authority and responsibility is likely to be bestowed on the center. Therefore, positioning the center at the highest level possible provides the “measure of autonomy necessary to extend the authority across the organization, while substantiating the value and importance the function has in the eyes of executive management” (Bolles, Dennis PMP. Building Project Management Centers of Excellence. New York, NY: American Management Association. 2002). In the absence of high-level positioning, the success and impact of the center will likely be significantly diminished.

One Size does not fit All

The “perfect fit” takes several elements into consideration:

The maturity of the organization’s processes and capabilities
The size of the organization
The diversity of the products and services

What is the Focus?

The current state of the organization must be taken into consideration, as in the effectiveness of the strategic planning and project portfolio management practices, the business performance management processes and strategies, the maturity of IT architecture, development and support processes, and the strength of the business focus across the enterprise. Clearly, organizations with more mature practices achieve higher levels of value from their COEs. Organizations can absorb a limited amount of concurrent change, while maintaining productivity levels, at any given time. Therefore, a gradual approach to implementing the BACOE is recommended. One option is to adopt a three-phased approach moving across the BACOE maturity continuum from a project-focused structure to a strategic organizational model.

Where to Start?

Based on the history of best practices for setting up centers of excellence, there is a proven implementation approach, including the steps listed below.

Visioning and concept definition
Assessing the organizational knowledge, skills, maturity, and mastery of business analysis practices
Establishing BACOE implementation plans
Finalizing plans and creating action teams to develop and implement the infrastructure for the center

Visioning

It is important to create a vision for the new center. Create a preliminary vision and mission statement for the center, and develop the concept in enough detail to prepare a business case for establishing the center. Vet the proposal with key stakeholders and secure approval to conduct the assessment of business analysis practices and plan for the implementation of the center.

During meetings with the key stakeholders, secure buy-in and support for the concept. Large-scale organizational change of this nature typically involves restructurings, cultural transformation, new technologies, and forging new partnerships. Handling change can well mean the difference between success and failure of the effort. Techniques to consider during the visioning phase include (Kotter, John P. (2002) Getting to the Heart of How to Make Change Happen. Boston, MA: Harvard Business):

Executive sponsorship – A center of excellence cannot exist successfully without an executive sponsor. Build a trusting, collaborative relationship with the sponsor, seeking mentoring and coaching at every turn.
Political management strategy – Conduct an analysis of key stakeholders to determine those who can influence the center, and whether they feel positively or negatively about the center. Identify the goals of the key stakeholders. Assess the political environment. Define problems, solutions, and action plans to take advantage of positive influences, and to neutralize negative ones.
A sense of urgency – Work with stakeholder groups to reduce complacency, fear, and anger over the change, and to increase their sense of urgency.
The guiding team – Build a team of supporters who have the credibility, skills, connections, reputations, and formal authority to provide the necessary leadership to help shape the BACOE.
The vision – Use the guiding team to develop a clear, simple, compelling vision for the BACOE, and set of strategies to achieve the vision.
Communication for buy-in – Execute a simple, straight-forward communication plan using forceful and convincing messages sent through many channels. Use the guiding team to promote the vision whenever possible.
Empowerment for action – Use the guiding team to remove barriers to change, including disempowering management styles, antiquated business processes, and inadequate information.
Short-term wins – Wins create enthusiasm and momentum. Plan the implementation to achieve early successes.
Dependency management – The success of the center is likely dependent on coordination with other groups in the organization. Assign someone from your core team as the dependency owner, to liaise with each dependent group. A best practice is for dependency owners to attend team meetings of the dependent group, so as to demonstrate the importance of the relationship and to solicit feedback and recommendations for improvements.

Organizational Readiness

The purpose of the organizational readiness assessment is to determine organizational expectations for the BACOE and to gauge the cultural readiness for the change. Form a small assessment team to determine key challenges, gaps and issues that should be addressed immediately. The ideal assessment solution is to conduct a formal organizational maturity assessment. However, a less formal assessment may suffice at this point.

Planning

Develop a BACOE Business Plan and Charter that describes the center in detail. Planning considerations include the elements listed in the table below. It is helpful to draft the plan and charter, and then conduct a BACOE kickoff workshop where they are viewed, refined and approved.

Planning Considerations	Description of Kick-off Workshop Agenda Items
*Strategic Alignment, Vision and Mission*	Present the case for the BACOE, and reference the business case for more detailed information about cost versus benefits of the center.
*Assessment Results*	Include or reference the results of the assessments that were conducted: Maturity of the business analysis practices Summary of the skill assessments Recommendations, including training and professional development of BAs and improvement of business analysis practice standards
*Scope*	Describe the scope of responsibilities of the BACOE, including: The professional disciplines guided by the center, (i.e., PM and BA, just BA) The functions the center will perform The processes the center will standardize, monitor and continuously improve The metrics that will be tracked to determine the success of the center
*Authority*	Centers of excellence can be purely advisory, or they can have the authority to own and direct business processes. In practice, centers typically are advisory in some areas, and decision-makers in others. Remember, the organizational placement should be commensurate upon the authority and role of the center. When describing the authority of the COE, include the governance structure, i.e., who or what group the COE will report to for guidance and approval of activities.
*Services*	A center of excellence is almost always a resource center, developing and maintaining information on best practices and lessons learned, and is often a resource assigning business analysts to projects. Document the proposed role: Materials to be provided, e.g., reference articles, templates, job aids, tools, procedures, methods, practices Services, e.g., business case development, portfolio management team support, consulting, mentoring, standards development, quality reviews, workshop facilitators, and providing business analysis resources to project teams
*Organization*	Describe the BACOE team structure, management, and operations including: Positions and their roles, responsibilities, and knowledge and skill requirements Reporting relationships Linkages to other organizational entities
*Budget and Staffing Levels*	At a high level, describe the proposed budget, including facilities, tools and technology, and staffing ramp up plans.
*Implementation Approach*	Document formation of initial working groups to begin to build the foundational elements of the center. In addition, describe the organizational placement of the center, and the focus initially: (i.e., project centric, enterprise focus, or strategic focus).

Launch

After the workshop session, finalize the BACOE Charter and Business Plan, and launch the center. Form working groups to develop business analysis practice standards, provide for education, training, mentoring and consulting support, and secure the needed facilities, tools, and supplies.

Final Words

Establishing centers of excellence is difficult, because it destabilizes the sense of balance and power within the organization. Ambiguities arise when all stakeholders are adjusting to the new model. These may manifest themselves as resistance to change, and can pose a risk to a successful implementation. Therefore, coordinate and communicate about how the center will affect roles and responsibilities accompanies the implementation of the center. Do not underestimate the challenges that you will encounter. Pay close attention to organizational change management strategies and use them liberally.

Value to the Organization

To establish BACOE to last, demonstrate the value the center brings to the organization. Develop measures of success and report progress to executives to demonstrate the value added to the organization because of the BACOE. Typical measures of success include:

Project cost overrun reduction – Quantify the project time and cost overruns prior to the implementation of the BACOE, and for those projects that are supported by the BACOE. If a baseline measurement is not available in your organization, use industry standard benchmarks as a comparison. Other measures might be improvements to team member morale and reduction in project staff turnover. Be sure to include opportunity costs caused by the delayed implementation of the new solution.
Project time and cost savings – Track the number of requirements defects discovered during testing and after the solution is in production prior to the implementation of the BACOE, and for those projects that are supported by the BACOE. Quantify the value in terms of reduced re-work costs and improved customer satisfaction.
Project portfolio value – Prepare reports for the executive team that provide the investment costs and expected value of the portfolio of projects; report actual value new solutions add to the organization as compared to the expected value predicted in the business case.

Great Teams…You Need One!

When staffing the BACOE, establish a small but mighty core team dedicated full-time to the center, co-located, highly trained, and multi-skilled. Do not over staff the center, as the cost will seem prohibitive. Augment the core team’s efforts by bringing in subject matter experts and forming sub-teams as needed. Select team members not only because of their knowledge and skills, but also because they are passionate and love to work in a challenging, collaborative environment. Develop team-leadership skills and dedicate efforts to transitioning your group into a high-performing team with common values, beliefs, and a cultural foundation upon which to flourish.

Don’t forget to leave your comments below

Kathleen (Kitty) Hass is principle consultant, K. Hass and Associates, specializing in strategy execution, business analysis and project management disciplines. Ms. Hass is a prominent presenter at industry conferences, author and lecturer. Expertise includes implementing a mature BA Practice, implementing PMOs, BACOEs, and portfolio management, facilitating IT strategic planning, leading software-intensive projects, executive coaching, building and leading strategic project teams, and managing complex programs. Her company provides high-value facilitation and consulting services to agile and traditional organizations. Ms. Hass has provided professional services to Federal agencies, the intelligence community, and Fortune 500 companies. Professional certification include: SEI CMM appraiser, Baldrige National Quality Program examiner, Zenger-Miller facilitator, and Project Management Professional. She is Director at Large for IIBA and a member of the BABOK committee serving as lead author of the Enterprise Analysis chapter. She authored numerous white papers and articles on leading edge PM/BA practices, in 2008 published the Business Analysis Essential Library Series; Managing Project Complexity – A New Model, and in 2009 contributed to The 77 Deadly Sins of Project Management. Ms. Hass can be reache at [email protected]

This article was originally published June 2009 in ModernAnalyst.com www.modernanalyst.com

Less than 10% Information Density!

Written by Robert Galen on August 18, 2009. Posted in Articles.

I left off my last post alluding to the need for conversation as part of the requirement process-continuous, reflective, emergent, and ongoing communication. The conversations in this case are face-to-face discussion amongst the constituents who are tasked with implementing a specific feature or component.

Even more importantly, those conversations need to be skewed towards doing the work-not simply talking about doing the work. They occur while developers are writing and testing their code, reviewing snippets of working design. They occur while testers are testing snippets, small slices of working code, and seeing what works and what doesn’t-providing that feedback to the developers. They occur while the team shows the customer snippets of working code, checking if it meets expectations and providing real-time feedback. And they occur when the functionality is considered complete and checked off as done.

In a 1967 study, Mehrabian and Wiener analyzed the effectiveness and coverage of human communication. In that study, they found that written communication (documentation, email, instant messaging, etc.) only makes up about 7% of the overall information density potential of communication potential. The breakdown follows.

7% of the communication bandwidth / potential was in the language
38% …was in the Inflexion
55% …was in the body language

Now there has been quite heated debate surrounding that study and how it may be applied. That it wasn’t focused on technology information exchange, but rather more emotionally charged communications. However, while I agree that it may be skewed, I also think there’s an important message embedded within it for our technical information exchange.

It’s that written documentation is probably the most error prone and least rich way for humans to communicate. Diagrams, pictures, and models certainly help-raising the bandwidth of the communication. However, the richest type of communication is when we interact face-to-face as teams. Where we can see each other and interact in that richer and higher capacity medium.

From a design perspective, some of my most successful projects were architected or designed collaboratively at the whiteboard and not at a computer. A small group gathered around the board and hashed out the design. We drew alternatives and discussed them-face-to-face. We explored strengths and weaknesses and reacted to what each others’ suggestions or critical points. When we looked back at the project, the entire team felt it was these critical moments of collaborative communication that were an important part of our critical success criteria.

In my last post I als spoke about the nature of the agile requirement artifact – the User Story. Stories are small, terse artifacts, which are left intentionally incomplete.

When an agile team plans a Story, they don’t invest too much time in it up front. Oh, they discuss it to understand the high level implications, but they defer much of the detail to later. They estimate it at a high level, while also deferring implementation details.

When they’re planning the Story for their very next iteration, they ask more questions, but again, not exhaustively. They also break the Story down into tasks for execution, and that helps drive additional conversation. Still, though, they have only explored 30, 40 or 50% of the clarity surrounding the guts of the Story.

It’s when they actually start to work on it that they flesh out the remaining details, usually in small groups. It’s this wonderful strategy of iteratively defining (and refining) your requirements that’s at the heart of agile methods. It’s allowing yourself to not fill in all of the blanks until you learn more…as you go, in a Just Enough and Just in Time fashion.

Now this is all fine, you might say, for small, co-located teams that can actually have face-to-face communication. What happens when you have real-world larger scale teams that are in distributed locations? Can these approaches still work? If there’s enough interest shown via comments that might be where I go next…

More information on the Mehrabian and Wiener study can be found here at http://en.wikipedia.org/wiki/Albert_Mehrabian

Don’t forget to leave your comments below

Robert Bob’ Galen is the President and Principal Consultant of RGCG, L.L.C. Bob has held director, manager and contributor level positions in both software development and quality assurance organizations. He has over 25 years of experience working across a wide variety of software technology and product domains. Bob can be reached at [email protected]