Categories
Document Management Rapid JAD

Getting It Right

Facebooktwittergoogle_plusredditpinterestlinkedinmail

by Erik Jul

When specifying requirements for a new system, large or small, how much do we have to get right?

Isn’t “All of it” the right answer?

Not always, and maybe never.

Concepts such as “minimally viable product” (which carries the moniker MVP as if it were some sort of champion), “iterative solution scoping,” and “progressive elaboration” decry the notion of completeness and possibly even that of correctness.

Of course, no one wants to deliver, or attempt to use, a system that does not work or is ill-suited to the task. So “getting it right” must matter to some degree: the system must work as specified.

But how much of what the user needs or wants has been identified and correctly specified in functional and other requirements? And of that, how much was correctly implemented?

Relying upon a Six Sigma approach (a methodology driving toward six standard deviations between the mean and the nearest specification limit) may reduce defects, but may still fall short of identifying a customer’s true problem and its best solution.

Lean, Lean Six Sigma, Agile, and the Three Amigos Scrum Alliance. These, plus approaches already forgotten or yet to be proposed, try to help us “get it right.”

In successive waves of innovation and reinvention, practitioners attempt to narrow the gap between what’s needed, what’s specified, what’s delivered, and what solves the customer’s problem.

Along that path, from problem to solution (scope, time, and cost notwithstanding), the professional solutions team—sponsor, business owner, project manager, business analyst, QA /tester, solution architect, developer, trainer, change management lead—all focus on “getting it right.”

Common software development and project management practices such as change requests, expectation management, phased releases, bug fixes, cumulative updates, and new versions testify that “getting it right” remains a noble goal seldom reached and maybe never reasonably expected.  For now, these are our best tools for getting it right, eventually.

To increase the likelihood of getting more right now rather than eventually, try these Rapid JAD principles: Capture Now, Document Once, Visible to All, and Revise Quickly.

Simple. Proven. Effective.

How much do you want to get right?

 

Facebooktwittergoogle_plusredditpinterestlinkedinmail
Categories
Uncategorized

Rapid JAD Advances Engagement Management

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Why Engagement Management?

Engagement Management is all about business and information technology (IT) teams working together. This may sound easy. Just talk and draw some stuff up. But effective and efficient communication at the level needed for software systems development can pose many challenges. Perhaps you are familiar with this great cartoon which illustrates the challenge of clear communication?


All of these individuals–the project manager, the architect, the developer, the salesman–can read and hear what is to be built, carry on a discussion about the project, and then set about working on just what they think they understand.

However, as Erik Jul points out in Visible to All, communication can be difficult. The larger the project, the more complex the solution, the greater the risk when it comes to clear communication.

Rapid JAD has a solution we call Engagement Management.   

Engagement management tightens the communication link among team members, customers, and stakeholders because all communications are:

  • Planned in advance
  • Clearly documented
  • Revised as needed, and
  • Available to all.

Making project information such as action plans, risks, decisions made, tasks, designs, and workflows readily visible aids the essential two-way communication needed to go from project inception to successful project delivery.

Who Needs to Be Engaged?

A communication plan will identify the stakeholders, their interest in the project, the format of the communication, how often to communicate, and who is responsible for the communication. Of utmost importance is identification of the business expert who will, on a daily basis, be available to answer questions that come up from the IT team. This business expert will be appointed by the business as the Product Owner.

The Product Owner, representing the business and the Project Manager, representing the IT team, work together on details of the communication plan and who will be responsible for the various pieces of the plan. Even in a large organization where tools are readily available, there still needs to be discussion and planning between the business and IT around communication.

Where Should Engagement Take Place?

Rapid JAD addresses two types of engagement: people (meetings) and artifacts.

For people, the ideal place for engagement is in the same room with a projector or shared visual display. This is not always an option as teams can be geographically separated. When geographically separated a tool such as Go To Meeting makes it easy to share what is being seen in one location with team members in another location. Some tools also provide video conferencing which is a plus for geographically separated teams. Whatever tool is used, shared visibility is key for people who are getting engaged with the system development. You want all members of the engagement capable of viewing the same objects.

For artifacts, visibility is again a key factor. Not only is collaboration important, artifacts need to be visible to all. Where do you put the project vision? Where do you put the requirements? Where do you put the designs? The workflows? The tasks? The issues? Project artifacts must be readily accessible and visible to all who are part of the project.  This engagement factor is key to success. 

What Focuses Engagement?

Artifacts, and their related processes, focus engagement.

Regardless of what is being worked on, team members from both the business and IT need to be engaged and jointly developing and reviewing project artifacts. Key artifacts for engagement are:

  • Project Vision
  • Requirements
  • Definition of Done
  • Change Management Plan
  • Story Boards / Wireframes
  • Business Workflows
  • Technical Designs
  • Design Decisions
  • Issues
  • Tasks
  • Risks
  • Milestones and Timelines
  • Team Roster & Contact Information

How Do We Accomplish All of This?

Collaboration tools greatly enhance engagement.  While the use of Collaboration tools varies from company to company,  half of the 379 respondents to a poll on the Intranet Professionals LinkedIn group indicated that their company uses SharePoint. To ensure success, regardless of the collaboration tool used, both the business and the IT team must be able to access and use the tool.

Collaboration tools provide a way for everyone on the team to be engaged with the current artifacts. Whether you are concerned with business workflow, interface design, technical decisions, or even project vision, having one location with the current information is critical.

The tools you use for engagement will play a large part in implementing the Rapid JAD principles for accelerated system design: Capture Now, Document Once, Revise Quickly, and Visible  to All.

When Should Engagement Start?

Informal engagement starts before a project is approved, during development of the business case and associated cost benefit analysis. Once a project is approved Engagement Management should start with identification of the Product Owner for the business and the Project Manager for the IT team. Together the two take ownership of the project and collaborate on the Engagement Management plan.

Facebooktwittergoogle_plusredditpinterestlinkedinmail