If you can't explain it simply, you don't understand it well enough.
~ Albert Einstein ~
"Many organizations are still accustomed to thinking in terms of projects. A project is an initiative with a finite length, a well-defined beginning, a specific scope to deliver, and usually a defined end date.
In contrast, a product is long-lived, often with no defined end...
If the product is worth developing, it needs to be funded and managed differently. Products require regular releases to meeting the ever-changing needs of product users. Products require a dedicated team to build and support the product across a series of releases, and they require that there is no difference between maintenance, new development, and enhancements from a product team perspective."
~ Bitner, Kong, West. 2018. The Nexus Framework For Scaling Scrum, pg. 3 ~
Business Model at RMMi
Solutions. Repeatable solutions happen with solid documentation of business need mapped to operational goals and traced through project delivery and product road maps showing successfully deployed solutions. Documentation such that new teams can come up to speed, such that reporting of metrics and key point indicators can be backed with facts, such that negotiation of delivered value can be prioritized.
At RMMi the goal is to bridge the communication between business operational management and technical service teams. The Business Systems Analyst role is a key model from which to discuss best practices, modes of representing ideas, frameworks to deliver predicable solutions.
The business model of RMMi is to consult and or contract with clients in various industry by bringing in a proven project list, delivered solutions, and fresh ideas with its thought leadership.
Brief Project list from the last 13 years
Clients and industry sectors have included; Xcel Energy / Public Utility, McKesson / Health Solutions, USDA / Federal Government, Sprint-Nextel / Telecommunications, and Fair Isaac / Financial Services.
Projects have included; Electronic Shift Operations Management - Implementation, Demand Response Management System - Implementation, Employee Charitable Giving Portal - Hosted Solution, Check Processing Management System - Upgrade, Regulatory Information System - Data Integration Compliance, Pipeline Data Project - Gas Transmission Data Integration into GIS, Field Collection System - ITRON upgrade, Advanced Diagnostics Management - Agile Product Management, Veterinary Services Bovine Tracking Management - Development, Health Care Claims Authorization Diagnostics Management - Development, Consolidated Data-warehouse Reporting - BRS Documentation, CRMS reengineering Pay for Performance KPI Solution, Reengineering Business Rules and Data Center Relocation.
RMMi Core Skills
At RMMi our core skills are within business systems analysis and software system upgrades, integrations and development. Also core skill is data modeling and integrations. These data skills are focused on master data management and reporting metrics operational data stores and data warehouse schema models, that best serve the solutions at hand.
At RMMi we have spent significant time in all things involved with corporate enterprise software development life cycle (SDLC.) Time spent elaborating and documenting in clear language that business can agree on and technologists can deliver.
Solutions. Best practices to documenting solutions both in the agile framework and the waterfall project cycles, RMMi takes pride in communicating steps to solutions.
Requirements Management
With a project to PMP standards or within the framework of Agile and Product Backlog, requirements must be clearly understood. To that end RMMi focus is full life cycle (SDLC) of the business needs.
Requirements management is ensuring that an organization documents, verifies, and meets the needs and expectations of its customers and internal or external stakeholders. Requirements management (or Backlog Management) begins with the understanding of the business need and alignment with the objectives and constraints of the organization. There are a variety of best practices to understand the requirements through which an Analyst reviews the users As-Is-Workflow and maps to a given set of features/solutions value position (road-map) to the business. One such focus area is traceability. In order to validate a need is delivered, the requirements framework ensures each step maps from project initiation or from product use scenario, as defined by the business, has been delivered.
The traceability thus established is used in managing
requirements to report back fulfillment of functionality and
operational value in terms of compliance, completeness, coverage,
and consistency. This communication tool supports change management as part
of requirements management in understanding the impacts to scope
with of changes of understanding in the requirements or other
related system or technical elements (e.g., functional impacts
through relations to functional architecture), and facilitating the
adoption of changes.
Requirements management involves communication between
the project team members and stakeholders, and adjustment to
requirement changes throughout the course of the project.
Business Systems Analyst
The Systems Analyst role, which is known by a handful of alternative names (B.A. or Business Analyst or Project Architect or Technical Analyst or Requirements Analyst), is the bridge between the business operating unit and the technical teams all within the Software Development Life Cycle (SDLC.) The SDLC or systems implementation of a solution or integration of data from dis-separate operational groups, for instance, all require an understanding of what needs to be solved, fixed, optimized, upgraded, integrated or deployed. This is done through documenting the details. The key job of an Analyst is to uncover these details and describe them with such things as Use-Cases, As-IS Workflow, State Diagrams, Scenario elaboration. All these document types are intended to describe how a business USER interacts with current systems or future planned systems.
The project or program/product all have at the core, user feature functionality that needs to be understood to either solve or plan for or communicate change related to new efforts to optimized the business.
There are many tools to accomplish this task and an analyst must not only know the core tools like MS - tools such as advanced use of Word or Excel spreadsheets or VISIO, but also how to represent Unified Modeling Language (UML) or Business Process Model Notation (BPMN), or use T-SQL native against Microsoft SQL-Server or Oracle or MySQL or PostgreSQL.
An analyst must be an expert communicator, have leadership ability to drive a team to goal, must manage the process and client relations with the project sponsor or business leadership. An analyst must not only navigate rapidly changing technology but also the soft skills involved with effective teams.
Process Reengineering
Reengineering is about looking for optimizations automations or
re-usable steps so that within a business unit or corporate
enterprise structure, all like kind steps are leveraged for
efficiencies. To do this, a complete understanding of the process
needs to be mapped and understood. Diagramed, discussed, exposed,
explained and represented in word and image. This original AS-IS can
be shown in a number of ways:
- UML or BPMN
- Flows
- Activity
- Use Case
- User Scenarios
Once a process has been 1) identified, it is 2) analyzed using
one or more technique listed above. When the teams involved
understand a process, they discuss and negotiate possible 3) design
options. When a design has been vetted and approved, it is then
ready to be 4) implemented and tested for production. In a nutshell
reengineering is a 4 phase process. In reality that cycle can take
months to achieve. So. Process reengineering is
about finding ways to streamline an organization.
Often, no one is responsible for the overall performance of the
entire process. Reengineering maintains that optimizing the
performance of sub-processes can result in some benefits, but cannot
yield dramatic improvements if the process itself is fundamentally
inefficient and outmoded. For that reason, re-engineering focuses on
re-designing the process as a whole in order to achieve the greatest
possible benefits to the organization and their customers. This
drive for realizing dramatic improvements by fundamentally
re-thinking how the organization's work should be done distinguishes
the re-engineering from process improvement efforts that focus on
functional or incremental improvement.
The contractor role must focus on reaching out to the business
Subject Mater Experts (SME) and understand processes in a way that
can be communicated back to the teams. Move forward with building
consensus and vision, and align options in with the corporate
charters. Outsiders like contactors are excellent for these roles
since often when one has been too long in one modality at work, one
overlooks details. Fresh pairs of eyes can spot details and express
them.
Solutions can be discovered once all aspects are understood.
Program Management
Some organizations use the concept of Systems Engineering where
others use program management.
There are the two different views of how programs differ from
projects. In one view, projects deliver outputs, discrete parcels or
"chunks" of change; programs create outcomes. The project manager's
job is to ensure that their project succeeds. The program manager,
on the other hand, is concerned with the aggregate outcome(s) or
end-state result(s) of the collection of projects in a particular
program.
According to the view that programs deliver outcomes but projects
deliver outputs, program management is concerned with doing the
right projects. The program manager has been described as 'playing
chess' and keeping the overview in mind, with the pieces to be used
or sacrificed being the projects. In contrast, project management is
about doing projects right. And also according to this view,
successful projects deliver on time, to budget and to specification,
whereas successful programs deliver long term improvements to an
organization. Improvements are usually identified through benefits.
An organization should select the group of programs that most take
it towards its strategic aims while remaining within its capacity to
deliver the changes. On the other hand, the view that programs are
simply large projects or a set of projects allows that a program may
need to deliver tangible benefits quickly.
Some say, the key difference between a program and a project is the
finite nature of a project - a project must always have a specific
end date, else it is an ongoing program.
In practice it is not clear that there is a clear-cut distinction.
Projects (or programs) vary from small and simple to large and
complex; what needs to be a managed as a program in one culture or
organization may be managed as a project in another.
While different clients have different ideas of scope of efforts,
the focus of RMMi is to achieve success in the timeline agreed to.
Project Architect
Solution architects are technology specialists who are called in
once an integration plan has been settled on. Their job commonly is
to take the work of a functional analyst and turn it into an
architectural plan that works. This plan will need to be researched,
built and tested repeatedly by the solution architect. Solution
architects will need to be knowledgeable of a variety of computer
programs like SharePoint, SDK tools, SQL Server and others.
Architects working in software create the framework for the software
development. While it is pivotal their design or model meets the
stakeholders' requirements, architects should also suggest design
elements that no one else considered but that add to the value of
the product for consumers. To accomplish their goal, architects may
divide the project into smaller pieces, ensuring each part of the
computer system works together. Additionally, they may have to
determine what features or elements to include or leave out based on
cost and time. They also plan for future builds, as some of their
design scaffolding can be used in other applications and systems.
The ability to see the big picture, and understand the corporate or
organizational constraints that the technical and functional details
of the SDLC must fit within. At RMMi, it is the depth of experiences
that allow us to fill this role for clients.
Project Leadership
A great book on leadership, I feel, is The Dichotomy of Leadership which states in a nutshell the following:
- When to lead and when to follow
- When to focus and when to detach
- When to tighten the reins and when to let the team run
- when to aggressively maneuver and when to be prudent.
Project leadership is working with the teams to achieve goal. At
times you are the Project Manager, or Architect, or Analyst, or
other roles in the scope of delivery of solutions. The leadership of
a strong team isn't always about the hierarchy or title of a person
in a role. Leadership is about vision compassion focus and bringing
the whole group forward.
There are times when members of a team are burned out, overloaded,
under-skilled, or maybe trouble at the home front is interfering
with task delivery. A leader, keeps on eye on everyone, including
their own health, and communicates individually or with the group.
Speaks up during scrums, pays attention while participating in
technical or design reviews and engages.
Leadership is about doing what it takes, to complete the
mission. Do a solid job so you get referrals and call backs to do
more projects. Standing up and getting done what needs to be done.
Additional Skills
- Communications
- Technical Writing
- Public Relations
- Marketing
- Ideation
- Motivational
- Coaching