Tag: Team

An Eye for Value: What the Business Analyst Brings to the Agile Team

Written by Cynthia Low on March 31, 2008. Posted in Articles.

There’s no question about it: agile project management expedites the new product development process. It is a streamlined methodology, based on having only essential people work in tight knit teams for quick and efficient results. Of course, one very important member of the team is the business analyst. Why? Because if companies hope to achieve strategic goals, they need someone who is focused on the business value expected from the project outcomes to help provide guidance, not only during a project, but also before it is invested and after it is delivered.

In traditional project management, which comes from the construction industry, a great deal of up front planning and requirement generation is done. People can then walk away with finished plans in hand to construct a building. Though it is a logical approach for construction, project management has been adapted over time into an agile system for business projects that contain a significant technology component. For such tasks, it is difficult to articulate requirements for a future way of working that has not yet been tested. Agile projects proceed on more of a ‘learn as you go’ premise where small working teams include customers and developers who are co-located and spending 100 percent of their time dedicated to the project. The work is done in increments, and quick iterations are continually evaluated and modified. A project manager and a business analyst each play a crucial role on such a high performance team.

A project manager is essential for overseeing a product development project and making sure it comes in on time, on cost and with full scope. The business analyst is key in managing the evolving business requirements and the business benefits. According to the International Institute of Business Analysis (IIBA), the official definition of a business analyst is a person who works as, “a liaison among stakeholders, in order to elicit, analyze, communicate and validate requirements for changes to business processes, policies and information systems. The business analyst understands business problems and opportunities in the context of the requirements and recommends solutions that enable the organization to achieve its goals.” With the advent of agile product development and the constant requirements evaluation and modification within a project’s lifecycle, the business analyst is more valuable now than ever before.

The business analyst involvement in agile projects, unlike that of the project manager, is not limited to the period of time when the projects are active. Business analysts provide continuity for companies, from cradle to grave, by working with portfolio management teams to make sure the most valuable projects are being invested in, providing oversight during projects, and finally measuring actual benefits after projects are completed.

Chart a Course with Portfolio Management

Portfolio management is a relatively new practice, which is coming into its own as organizations better understand the importance of how choosing the right projects to invest in helps them to achieve their goals. When involved in the early planning stages, business analysts serve a company by providing enterprise analysis. By evaluating the competition and conducting benchmark and feasibility studies, business analysts identify business opportunities and create a list of potential projects to support.

Next, the business analyst puts together a business case in which they analyze the best approach to a particular project and show quantifiable benefits. After all potential solutions are studied and analyzed individually they create concise project investment decision packages for the optimum solutions to present to portfolio management steering groups or governance committees.

Created with the right expertise and tools, these project investment design packages provide the information for proposed projects in a consistent way. Such a presentation allows the executive level decision makers to compare apples to apples, the expected value, cost and risk of one proposed project versus that of others. The decision-making boards can then wisely select and prioritize major project investments.

Stay the Course During Product Development

Once a project is approved and funded, a project manager is assigned to technically manage it. Ideally, a business analyst will continue to oversee and elaborate the business requirements and benefits they originally helped to define. The two professionals have different but complementary roles in the product development process. Through team leadership and collaboration, they successfully guide an agile project that is both efficiently and effectively run, and that has significant long-term benefits for the company.

A business analyst’s main priority, when first attached to a specific project, is to elicit business requirements and categorize them into valuable features or functions. Then each feature is described in enough detail to determine its cost versus its benefits. By knowing what it will take to deliver each individual component of the project, as well as what the return will be to the organization, the development team can then build components or features based on value, and deliver the highest value features first.

As an agile project progresses through its lifecycle of requirements, design, construction, testing and deployment, the team continually learns new information. It becomes clearer how many resources will be needed to perform detailed design, construction and tests, how much risk there is to the project and how the risk needs to be managed. Accordingly, it is important to go back and check original assumptions concerning costs to develop and operate the new solution and business value to see if they are still true.

Working with the project manager and the core team of developers and customers, the business analyst updates the business case at key milestones throughout the project and adds more detail to the project plan. For example, the business analyst may discover that a project is going to take 12 months instead of six, and will cost 10 million dollars instead of eight. The portfolio management team needs to be informed, so that they can decide if the project is still a good investment and if it should continue. The business analyst will make valuable recommendations, such as continuation with some sort of course correction, like a scaling down of the requirements.

Because agile projects often involve upgrading information systems, it can be easy for the technical developers to focus on what technology can do, rather than on how technology can best serve the specific goals of the company. Throughout the constant adjustments in the development process, the business analyst always keeps the focus on the business requirements, the costs and risks involved and what value the project will ultimately return to the organization.

The role of liaison between developers (engineers who may not understand the intricacies of the business process) and customers (business people who may not know what exactly to request technologically) is an important one. Alice Zavala, Senior Consultant for Management Concepts in Euless, Texas, gives the following example: An agile team was working to create a new company website, and the customer asked for a drop down menu with both credit card and check payment options. The developer has the know-how to create what is asked for, which is basic information on an aesthetically pleasing background, but there are business rules that need to be applied to the process that were being overlooked. In this case, the business analyst bridged the gap between what the customer requested and what the developer needed to provide, by proposing a back screen to perform an approval process before the credit card or check goes through. According to Zavala, such a situation requires oversight because, “in order for information to be put on the screen, we needed to know what other business processes are going to be touched.”

By being involved during the development process, business analysts validate that new components are actually meeting business needs. They also take information to other groups outside of the agile team, to further corroborate that the changes have the support of other stakeholders, who will also benefit from revised requirements or at least not have conflicting requirements that need to be addressed.

The Finish Line and Beyond

In conjunction with the cost of the development of a new business solution, the operational component needs to be analyzed and assessed before the project is implemented. With a major new business system, perhaps there will be a need for some reorganization, retooling, retraining, or acquisition of new staff. Working with management, the business analyst helps to insure the organization is prepared for the impact of the changes. That way, when the final system is ready, it can be operated optimally.

Once the new system is in place, the actual costs of development / acquisition and operation should be compared to its actual benefits to the company. If a business analyst has been involved from the beginning of the process, he or she will have created a business case containing projected quantifiable benefits, which can be measured against the end results. This final analysis shows the organization whether they have received their predicted return on investment. If the performance metrics show that the project was a success, great. If not, the business analyst can investigate to find out where the project went wrong. Was it a bad investment because it was too high risk? Was the project executed poorly, so that the project cost a lot more than expected? Was the organization not prepared for the new system, so that operating costs are much higher than predicted? This type of post-project evaluation is crucial to improving future projects because it allows a company to learn from its mistakes.

Team Players

With all of the opportunities enabled by new technology, businesses are establishing strategic goals to keep up with the times and stay ahead of the competition. To both set and achieve their goals, they rely increasingly on the skills of business analysts, who can not only assist in making projects successful, but help select and prioritize those projects with the most business value, and analyze the effectiveness and worth of a deployed system.

The project manager and the business analyst are both integral in creating a high performance agile team. While the project manager’s role is more technical (keeping the project running smoothly) the business analyst’s role is more strategic (provided the team with a road map). Without a business analyst on board, with an eye on strategic company goals, an agile team can be like a high performance car without a navigator – making good time, but not sure where it is headed.

This article first appeared in PM World Today eJournal. www.pmworldtoday.net

Kathleen Hass, PMP , is the Project Management and Business Analysis Practice Leader for Management Concepts, Inc. and has more than 25 years of experience in project management, including project office creation and management, business process re-engineering, organizational development, software development, technology deployment, project management training, mentoring and team building. For more than a quarter of a century, Management Concepts, Inc. has provided quality training and performance improvement solutions for the mind at work. For further information, please call 703.790.9595 or visit the company website at http://www.managementconcepts.com/.

Personal Identification: The Soft Skills PRECEDE the Hard Skills, for BAs

Written by Marcos Ferrer on March 31, 2008. Posted in Articles. 2 Comments on Personal Identification: The Soft Skills PRECEDE the Hard Skills, for BAs

Doggone and dadblast it, what is going on! Didn’t I just say the opposite last month? How is your tolerance for ambiguity holding up? Are you on top of the BABOK 1.6 BA Fundamentals? If you are aspiring to the top of your profession, and have the courage to self-identify, dive right in!

I begin by quoting the entirety of BABOK Chapter 8 here (don’t panic, it fits in the blog):

Chapter 8: Underlying Fundamentals
8.1 Introduction

8.2 Basic Skills
8.2.1 Analysis Skills
.1 Structured Analysis Techniques
.2 Issue Management
.3 Communication Skills
.4 Learning Skills
.5 Usability

8.2.2 Business/Domain Knowledge
.1 Products
.2 Processes
.3 Markets
.4 Systems
.5 Sources of Knowledge

8.2.3 IT Knowledge
.1 Paradigms
.2 Methodologies

8.3 Advanced Skills
8.3.1 Meeting Management
8.3.2 Presentation Skills
8.3.3 Decision-making Skills
8.3.4 Facilitation Skills
8.3.5 Communication Skills
8.3.6 Conflict Resolution
8.3.7 Negotiation Skills
8.3.8 Relationship Skills
8.3.9 Questioning Skills
8.3.10 Systems Thinking
8.3.11 Escalation Skills
8.3.12 Logic
8.3.13 Cultural Awareness

8.4 Leadership Skills
8.4.1 Coaching Skills
8.4.2 Facilitating Long-term Goal Setting
8.4.3 Motivational skills
8.4.4 Appraisal Skills
8.4.5 Interviewing Skills
8.4.6 Role Definition
8.4.7 Behavioral Coaching
8.4.8 Delegation skills
8.4.9 Succession Planning
8.4.10 IT Architectural Skills

8.5 Peripheral Skills
8.5.1 Sales

8.6 References

Interestingly enough, it is only the Basic Skills that have any detail at all, and those not much. What does this mean? The Basic Skills are the things that we learn just by doing IT requirements work. So many BAs cut their teeth on IT, that this is “self-evident” to many of us. The KEY skill is that we LEARN.

Self-test number 1:
Did you love school, or at least did you love reading and learning? Can you see the relationship between a three-year IT project and a three-year PhD program? WHY is it important to involve stakeholders (bet you don’t know)?

Next are the Advanced Skills. These are the sorts of things that BAs learn when (typically) we have been in a job long enough to have institutional knowledge and process experience, plus enough maturity to get along. In effect we get “promoted” to working with more people. We may not be good at it at first, but we’re here because we know so much and can share it. This thrusts us beyond analysis of processes affecting teams, into the processes of team analysis. We can lead the team to meetings, but can we make them think?

Self-test number 2:
How balanced were your SAT scores? Are you as comfortable with words as you are with complex IT and financial concepts? Would you rather listen, except when it is vital to talk?

Then comes Leadership Skills. This is Advanced Skills on steroids, in the sense that NOW you can really make it work, not just oversee uninspired meetings and team sessions.

Self-test number 3:
Do people just fall all over themselves to be with you and get your approval and do what you say because you are just plain charismatic and, frankly, too sexy for your project? If not, have you held at least one sales job for more than two years? If not, try it and find out if you want to lead.

Yes, this is the punchline. Leadership IS influence, regardless of style, or outcome. Sales IS the profession of learning to influence, for good or for evil (both kinds of leaders are out there – which will YOU be?).

SO, as you look for “people skills”, don’t forget that a successful sale means a happy customer, whether the customer is a stakeholder, an executive, a system user, a boss, or an IT team member.

Happy customers are getting what they want – good systems; no one loves a salesman who sells a lemon. If you have happy customers, you are on your way to the top of the profession.

Here is the problem we have posed: BUT, loyal reader, I am out of time this month.

Road to the Perfect Project Part 3

Written by Cynthia Low on February 15, 2008. Posted in Articles.

Limit Formal Process

Many projects today, especially the larger, ones are run based on what I call “big process”. Development organizations get their systems and software engineering processes and procedures CMM/CMMI certified. This means that anyone working on their projects lives in a world controlled by a myriad of plans and processes covering all aspects of that project. Projects in these organizations will also be documentation heavy – typically based on IEEE standards. There are very good reasons for the existence of big process. These processes represent best practices distilled from decades of corporate experience. Big process does provide order and consistency to projects. The intention is to ensure consistent results. The project team just follows the system cookbook and all comes out well.

The biggest problem with this approach is that all the process is, at its heart, intended to do is allow average quality staff to reliably deliver “acceptable” systems. And most of the time it delivers. Now, if all you want is an acceptable (read mediocre) system, then by all means go for it. For big process to work properly the project team should come onto the project already immersed in the company’s methodology based on actual prior experience with it. A very real problem with this approach in the government contracting world is that the development contractors do not keep stables of ready and willing people who have been deeply immersed in the company’s methodology on prior projects. When they win a contract they go out and hire mostly new people for the project, who then have to go through a long period of training and adjustment to the company’s methodology.

Big process tends to force big project size – and big project cost. Typically there exist separate sub-organizations for requirements management, systems engineering, software engineering, development, testing, configuration management, quality control, risk management, etc. And all of that process increases the amount of work (much of it administrative in nature), and also increases the communication load on the project. On a project with a smaller team, much can be done via informal channels where formal process would be needed in larger projects. Proper choice of support tools can improve productivity, and those tools come with built-in process. So using them gives you desirable best practice methodology without the need for separate formal written processes to deal with.

The primary uses for project documentation are (a) to allow the system to be developed and fielded, and (b) to support post-implementation system maintenance. I recommend limiting formal documentation to that which is truly needed. I believe a project needs a high quality set of formal system requirements, and a matching system test plan. Some level of design documentation is needed, with the higher level design being more important than the more detailed design. Depending on system complexity as well as security needs, other documents will be necessary. I believe it becomes a waste of money to continue to maintain anything but the highest level documents for purposes of system maintenance. Below a certain level of documentation needed for orientation purposes, maintenance people assume (largely correctly) that the documentation is out of date, and in any event they often prefer to just directly go to the code.

Exhibit Agility

Given that other conditions are extant, namely there is a small project; it is staffed with a solid leadership team; the project team is in a partnership mode with its customer; and the project is not overburdened with formal process, it becomes possible to take the final step to achieving the perfect project. The two most successful projects I have personally been involved in met these criteria, but also exhibited characteristics that now are associated with what is known as the Agile Methodology. The essence of “Agileness” is the ability to let things flow freely, and to operate intuitively versus slavishly following a rigid set of rules. It requires a high tolerance for ambiguity, and a willingness to quickly change direction, perhaps even radically. The team has to be fast on its feet.

Agility can be exhibited in any manner of ways. From the perspective of the project manager, that person may express agility in being able to rapidly shift assignments, based on knowledge of their subordinate team member’s individual experience and capabilities. This might be in response to a technical roadblock, a customer shift in priorities, or loss of a staff member. An individual analyst may need to multiplex multiple assignments, and be willing to instantly shift what they are doing based on project needs of the moment.

Agility also means thinking out of the box about how things are done. Consider system requirements. While I am a big believer in starting out with a solid set of formal requirements, one has to understand that those requirements are just an initial guess at what the system’s users truly need. It is right and proper to put together an early version of the system based on those requirements. But early pre-release user exposure will almost certainly identify various needs for adjustment. There may even be a need for significant rework. The agile team will, quickly and gracefully, make accommodation for them, even if major rework is needed. The users will deeply appreciate it. But at some point, typically after the first system release (but perhaps even earlier), it will make sense to just abandon those original requirements, and any attempt at traceability to them. The agile team then goes into change management mode and allows the system to morph into whatever it wants to become, as user complaints and suggestions for improvement pour in.

Not everyone is capable of what I used to call “go with the flow development”, and not every customer will allow it, but a project team that is able to operate intuitively can produce absolutely spectacular results.

John L. Dean is a seasoned IT professional with 40 years of varied experience, including systems engineering, systems analysis, requirements analysis, systems architecture and design, programming, quality assurance, testing, IV&V, and system acquisition, equally split between technical and management. He has worked both the contractor and government sides of the fence, has been an employee of large (IBM, CSC, Booz-Allen, MITRE, ACS) as well as very small companies, and is currently an independent consultant. He has a Masters degree in Operations Research from Clemson University. John is the “Project Whisperer”. His depth and breadth of experience gives him an unusual perspective on what does and does not work. If your project is running you, he can use his experience and intuition to diagnose why and apply calm, assertive energy to start corrective action, so you can and regain control! He can be contacted at [email protected].

Road to the Perfect Project – Part 2

Written by Cynthia Low on January 31, 2008. Posted in Articles.

Project Leadership is Critical

The most important person on a project is the project manager. A good project manager with a supportive management style can make a project, and a bad one with an aggressive management style can single-handedly cause it to fail. I have seen both happen. As an ideal, the project manager will have personal technical experience that matches functionally the work being performed on the project. For instance, if it involves requirements elicitation, he/she should have personally done that kind of work. In a cradle to grave development effort, the more technical breadth that individual has the better. They absolutely must have excellent writing and presentation skills, and must be able to interface with both the customer and their own line management. The project manager has to have had management experience, some of which should be at the level required for the project.

After that, it is critical to select a high quality set of senior analysts for the project. This includes both business analysts and systems analysts. These people must have the requisite technical skills and experience to match the project’s needs. For example, a project might need senior analysts with skills in requirements management, database management, system architecture and design, and system testing. At a minimum, they must have successfully done the type of work to be performed. If specific tool sets are to be used, in the ideal they will have worked with those tools. As with the project manager, communication skills are a must. In addition, some supervisory experience is needed. Ideally there will be some experience overlap. For instance, a person with both requirements management and system testing skills is more valuable than someone who only has requirements experience because they can cover for a missing system tester.

I will call this set of people the Leadership Team. The Leadership team must be individually flexible, and able to work together as a team. That is, they must be team players. Positive interpersonal dynamics among this set of key people must exist. Achieving consensus should be more important to them than individual heroics. If the team clicks, and they work together synergistically, the whole does indeed become more than the sum of its parts. In my experience, it is impossible to completely staff a project with super stars. They just are not going to be available when needed, and the cost is prohibitive. But given the existence of a synergistic leadership team, it is quite workable to use journeyman, and even some junior level staff for all remaining project functions, provided that the Leadership Team monitors and mentors them.

The reverse of the staffing coin is to ruthlessly cull out poor performers or discontents at any project level or role. These people can directly cause technical problems, and they will indirectly adversely affect project morale. If they are allowed to linger on the project they can and will make costly mistakes and they can and will negatively impact the performance of other project team members. It can be really painful to dump a malcontent, especially one who does not want to go. HR departments do not like wrongful termination suits no matter what the merits. Regardless, suck it up, and do what it takes to get rid of them.

Partner with Your Customer

To bring a system into existence, there is generally a project organization that is doing the work and a customer organization that has a need for a system and is financing the project. In my personal experience the customer has been a government agency, which provides the experience base for this discussion. Unfortunately, as many have experienced for themselves, there is a tendency for the customer to try and dominate the customer-project relationship. All too often the customer tries to rule by intimidation and, all too often, they force non-optimal technical decisions. This creates a jointly adversarial relationship. And that causes poor project morale, lackadaisical effort, and high project turnover. Results are typically poor. In short, you can have a great project team and still fail due to the customer not holding up their end.

To improve the project’s chances of going smoothly, those two organizations need to work in concert, where mutual trust, joint responsibility, transparency, and good will are operative. When real partnering does occur, and both sides hold up their end of the bargain, results tend to be excellent. Technical people enjoy their project; they work harder, and they stay around. The customer tends to get a more user-friendly system, which they are happy with. It is a win-win situation.

Most of you will have only worked the project side of this relationship, and if you are lucky you may know what partnering looks like from the project side. I have personally worked both sides of the fence. Here is what partnering looks like from the customer perspective. It starts with the RFP. That document is well written, and expresses exactly what the customer expects the project to do and deliver. If a set of system requirements is provided with the RFP, it is professionally produced and clearly and fully expresses what the system is to do without forcing major design decisions. This will allow the project to correctly estimate project costs and make proper staffing decisions. On startup, the customer provides a briefing to the project staff, at which time any applicable existing documentation is turned over to the project. The project is invited to do its own briefing on how they plan to do the work. If on-site, adequate space, workstations, and connectivity are provided on day one. Even if off-site, some dedicated space, including a small conference room is provided. Technical questions and issues posed by the project are promptly and fully addressed. Access is provided to potential users, either for requirements elicitation (the ideal), or requirements validation and expansion. Customer people attend all project briefings and project peer review sessions to which they are invited. Deliverables are promptly and thoroughly reviewed, and well-written formal comments are provided to the project. If needed, meetings are held to resolve conflicts. If the project is big enough, joint configuration control and risk review boards are formed.

On the project side, transparency is critical. Nothing is hidden from the customer. Any problems encountered are promptly conveyed to the customer for joint consideration. Schedules are rigorously met; documents produced are of high quality, including lack of grammatical or spelling errors; emerging user interfaces are offered for user review, and appropriate adjustments made; staff of the appropriate quality are placed on the project and vacancies are promptly filled.

Look for Part 3 of this series in the next Business Analyst Times online in mid-February.

John L. Dean is a seasoned IT professional with 40 years of varied experience, including systems engineering, systems analysis, requirements analysis, systems architecture and design, programming, quality assurance, testing, IV&V, and system acquisition, equally split between technical and management. He has worked both the contractor and government sides of the fence, has been an employee of large (IBM, CSC, Booz-Allen, MITRE, ACS) as well as very small companies, and is currently an independent consultant. He has a Masters degree in Operations Research from Clemson University. John is the “Project Whisperer”. His depth and breadth of experience gives him an unusual perspective on what does and does not work. If your project is running you, he can use his experience and intuition to diagnose why and apply calm, assertive energy to start corrective action, so you can and regain control! He can be contacted at [email protected].

Road to the Perfect Project

Written by Cynthia Low on January 14, 2008. Posted in Articles.

Introduction

Ever since software development projects have been around, people have been coming up with ways to help ensure they come out well. Unfortunately, history shows us that there is no process, methodology, or toolset that can guarantee project success. But there are some practical techniques, many of them non-technical, that can dramatically improve a project’s chances.

In this, and in the next couple of postings of Business Analyst Times, I will lay out techniques based on observations from my own personal experience that I know can reliably produce excellent results. In combination, they can result in what is experienced as a “perfect project”. I present from more of a project management perspective rather than pure BA one, because my experience has been that management activities and decisions tend to impact projects, for good or ill, more than technical ones. The ideas that follow are in approximate order of importance. They are necessarily quite brief, and each one is expanded in future postings.

1. Keep the project as small as possible. A project’s size is inversely proportional to its chance of success. As people are added to a project, the potential number of interactions increases pretty much exponentially, and things fall through the cracks, often catastrophically.

2. Carefully select a leadership team comprised of a project manager and key business and systems analysts. They must be highly qualified technically and must work together well as a team.

3. Create a partnership relationship with the customer. To improve the project’s chances of going smoothly, these two organizations need to work in concert, where mutual trust, joint responsibility, transparency, and good will are operative.

4. Limit formal processes and documentation to a minimum. “Big Process”, as exemplified by CMM/CMM and the IEEE standards can get in the way of a small sized project with high quality, motivated people.

5. Work intuitively. Operate at least partially in the mode exemplified by the Agile Methodology. By being highly flexible and willing to change as users are exposed to the emerging system, the probability of system acceptance is greatly increased.

Anyone who has been around a while knows that the conditions for achieving the perfect project are not commonly present. But, if they do exist where you now are, or you can influence things to cause them to exist, then enjoy your perfect project.

Keep Project Size Small

My experience has been that project size, in terms of the number of people working on that project, is inversely proportional to its chance of success. I have been around several projects that had 100+ staff. While none of them outright failed, none of them came out particularly well. In one instance, a literal handful of people (myself included) redid one of those large systems in a year of intense work, and turned a mediocre system with poor performance characteristics into a roaring success.

Why do large projects have problems? In a nutshell, the active principle is project communications. As people are added to a project, the potential number of interactions increases pretty much exponentially. The result is that important communications don’t always get to all necessary recipients, and things fall through the cracks. Mistakes are made, and they can prove to be disastrous. People feel isolated, morale tends to be poor, and turnover is high. Big projects try to mitigate this by requiring huge amounts of formal documentation and by holding many, many meetings. The sheer mass of material makes it nearly impossible for individuals to read everything they need to read to stay up to speed on everything that might affect them. It also becomes almost impossible for any one individual to comprehend the full documentation set as a whole, meaning that there may be no one individual who understands the entire project.

Any project that has more people than can fit around a large conference table is going to experience degraded performance due to communications issues. Conversely, with a small team, any communications issues can be addressed face-to-face and be observed by the entire project team. Much can be done on an informal basis that would otherwise require formal process and documentation. For instance, the two persons responsible for both ends of an interface can sit down at a whiteboard and work out the interface, and then, instead of creating a formal Interface Control Document, they just send an email summarizing the design. When it comes time to test the interface, both parties can be present and can troubleshoot and fix any problems on the spot. I know this works, because I have done it.

A small, closely knit team of sharp people can work miracles. I have been lucky enough to have worked a few myself. I claim that with such a team, working informally and without undue process and documentation overhead, I can build a given system faster, with better quality, and with better user acceptance than can be done by your average 100-person team, working under what is considered best practice processes.

Some projects are just too big functionally to do them with a single small team. This is especially true if hardware and communications must be procured and integrated, facilities must be built, and national security data is involved. But it may be possible to cleanly partition the problem into a set of functions that can then be implemented using a set of closely cooperating small teams, with a top-level team comprised primarily of team leads. Each team then operates independently on its functional area, and the top-level team ensures that cross team issues such as interfaces get handled efficiently and effectively.

Look for Part 2 of Road to the Perfect Project in the next Business Analyst Times

John L. Dean is an IT professional whose long and broad experience base gives him an unusual perspective on what does and does not work. He has 40 years experience, mostly in government IT contracting, including systems engineering, systems analysis, requirements analysis, systems architecture and design, programming, quality assurance, testing, IV&V, and system acquisition, equally split between technical and management. He has worked on both the contractor and government sides of the fence, has been an employee of large (IBM, CSC, Booz-Allen, MITRE, ACS) as well as very small companies, and more recently has worked as an independent consultant. John has a Masters degree in Operations Research from Clemson University. He can be contacted at

[email protected].