Consulting - Services Offered
Kinds of Consulting Services Offered
Bryan Derman
(consultant & instructor)
In the process of helping organizations improve their capabilities, we deliver mixtures of the following services:
- (Off-Site) Artifact Reviews: Doing a formal artifact/workproduct review is sometimes just a starting point and, other times, is the entire objective.
- Project Reviews: Based upon some predefined goals, involves analyzing the current state of a project, mostly via on-site interviews with key participants, and making recommendations. Unlike the amusing television advertisement, we will also help implement the recommendations.
- Training: Gaining new skills and capabilities often begins with some degree of formal training, normally delivered on-site. We have modularized training resources that are often tailored for individual situations.
- Mentoring: Formal training positions people to efficiently proceed with the learning process that really occurs when dealing with the complexity of actual situations. Effective, on-site, mentoring greatly accelerates the solidification of the new capabilities and helps prevent "wrong turns" that can be very costly.
- On-Going Checkpoint Reviews: In addition to on-site mentoring, remote workproduct/artifact reviews can help ensure that "wrong turns" don't occur.
- Software Architecture Reviews: Sometimes, to support the early phases of a long-term project or to support a consolidation or technology-update effort, there's a desire to focus only upon the software architecture. During such occasions, we've been engaged to review the existing, sometimes preliminary, software architecture and help the architects and designers solidify the strategy and the architecture.
- Project Leadership: All our consulting engagements involve varying degrees of an "agent of change" role. When required, we have played this role explicitly, even to the extent of taking over the management of a project.
- Project Participation: Sometimes, due to a critical aspect of a project, it is desirable to have very senior participation in generating various work products. On various occasions, we've functioned as a production member of the team to produce Use Cases and Supplemental Specifications (Requirements Specifications), Sequence Diagrams, Architectural-level Class Diagrams, Development Plans, etc.
Each of these services is detailed in a section below.
Basic Engagement Philosophy
The general approach is always to transfer capabilities, not to simply get paid to generate work products. Essentially, this means that the approach is to "work ourselves out of a job" as quickly as possible.
We "practice what we preach" in many ways. This means that we work iteratively. As such, we expect an engagement plan to evolve based upon what we've learned. Although this is harder on the consultant, it means we're nimble and able to stay relevant. We also feel very strongly about adding value. As such, if we're not being perceived as adding value, we are comfortable with ending the engagement at any time.
(Off-Site) Artifact Reviews
Sometimes it makes sense, especially as an exploratory and/or introductory engagement, to start by performing some formal review(s) of selected project artifacts (work products). Artifact reviews are normally performed off-site and for some specific objective:
- sometimes just to get a 2nd or 3rd evaluation
- to get advice on specific topics or issues
- to get advice about what issues are present
Typically, the review involves the following:
- we're sent some documents (usually in Word format) or models
- we perform the review
- make changes to documents (using Word's change tracking) or models
- add comments to documents (using Word's comment feature) or models
- we formulate and write recommendations
If a document is "way off," then we'll typically just review/edit/comment on one or two examples of each major issue and return the document or model for rework, before proceeding with a complete review.
Most consulting engagements are initiated after some amount of communication conversation wherein we discuss and agree upon the requirements and objectives. This normally results in a preliminary plan for the engagement. Larger engagements often begin with an on-site, 1-3 day, project review that yields an analysis of the fundamental issues and a more detailed engagement plan.
On occasion, the engagement has been simply to do a project review. We look at the team, the process, issues, goals, technology, etc. and formulate recommendations.
In addition to on-site project reviews, we also do on-going, off-site artifact reviews.
In support of knowledge and skill transfer, we regularly do formal seminars on the following:
- Use Cases: A 1 to 1.5 day seminar, normally followed by a 0.5 to 1.5 day workshop that often uses actual project-related workproducts, depending upon the project's progress and status. Often the initial 0.5 to 1 day is attended by management and/or customers/stakeholders.
- Object-Oriented Analysis and Design: A 3 to 5 day seminar that starts with the Unified Process and progresses through requirements analysis using use cases and how to use the Use Cases and Supplemental Specifications (i.e., the requirements) to drive the discovery of an object-oriented software architecture, in a very repeatable way. The session then discusses various aspects of object-oriented design, including producing class diagrams. The seminar teaches and uses the basics of the Unified Modeling Language (UML) and is presented within the context of the Unified Process. Often the initial 0.5 to 1 day is attended by management and/or customers/stakeholders.
- (Rational) Unified Process: A 0.5 to 2 day seminar that can be geared for various audiences, from stakeholders and senior management to developers.
Training is normally part of a larger engagement model that includes follow-on, on-site mentoring and often some off-site, on-going checkpoint reviews once the team is rolling along smoothly.
The on-site mentoring aspect of an engagement normally spans many activities:
- Working directly with a team or a small collection of teams as an "on line" source of expertise. This is especially the case when ramping up the use of Use Cases to capture requirements.
- Working with the management team to help develop plans and tactical strategies as well as report issues, make recommendations and report progress.
- Participating in workproduct/artifact reviews.
- Helping produce customized template artifacts, often from a basis we supply.
The normal strategy is to limit mentoring, for a given team, to a maximum of 2-week duration followed by at least a 1-week, off-site availability. This helps illustrate the real progress being made because people are forced to deal with realities. Again, the objective is to transfer knowledge and skill to the team.
Having helped analyze why various projects have failed to accomplish a transition, it's become obvious that many failures could have been prevented simply by having an experienced resource that would have seen that a "wrong turn" was being taken. There are some well-understood points at which projects are most at risk for going astray. Using an experienced resource to review various plans and workproducts at crucial points is a very cost-effective way to prevent expensive, sometimes catastrophic, detours. Normally, such reviews are performed as off-site artifact reviews.
Developing a robust software architecture can be a crucial investment that pays huge dividends, over time. A well-abstracted, object-oriented software architecture can outlive the implementation. With constant and rapid technology changes attacking the lower-levels of the implementation and business-process changes attacking the upper levels, developing a resilient software architecture has become increasingly important with a large return-on-investment potential. A software architecture review usually takes one of two formats:
- an on-site interaction with the people responsible for the software architecture
- an off-site review of various workproducts/artifacts
- sometimes both
Often a software architecture review is a prelude to further involvement in a mentorship role, sometimes preceded by some training sessions.
We are consistently able to get a team to quickly operate in a cohesive way. This comes about by setting clear objectives and expectations, practicing what's being preached, aggressively dealing with issues and operating with inter-personal respect (and a little humor helps, as well).
Whenever attempting to transition a team, leadership is required to:
- convey a vision and it's value
- transfer that vision to a core group
- lead those people to accept that vision
- foster an environment wherein these people take that vision and begin to run with it and apply it and adapt it for their own use
As such, effective mentors also need to be good leaders.
Although the best return on investment is achieved by having us focus upon knowledge, skills and experience transfer, sometimes tight schedules have us helping to simply "crank out" some of the workproducts/artifacts. This has most often occurred for producing Use Cases and Supplemental Requirements, various planning and proposal documents and architectural-level class diagrams.
