Skip to main content

Tag: Stakeholder

Road to the Perfect Project – Part 2

Written by Cynthia Low on . 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].

 © John L. Dean, 2008

BA Rising

Written by Marcos Ferrer on . Posted in Articles. 1 Comment on BA Rising

So, last month I covered Business Analysis, and How I Came to Realize What It Was And What It Meant. This month, I want to go more into what it means, and why the increased influence of BA (and the CBAP certification) is so important.

The short version is this: Systems are increasingly important in our quality of life (are you on the no-fly list yet?), and good BA leads to good systems, bad BA leads to Gartner and Standish Group negative statistics (if you don’t know what these groups do, Google them). BAs don’t always have the influence it takes to prevent these bad outcomes, but they should, and they will, now that the IIBA has established some neutral standards.

So, why BA – why can’t we build good systems without it? PMs are trained to deliver on time and under budget, so what’s the problem? (Hint – How hard is it to deliver on time and under budget? How much have you got to spend by when?) If you read the literature, you will see that MOST causes of project failure are related to stakeholders and requirements. These are failures of BA, by definition of the profession, and by default since they are not key to PMI.

I want to make the statement that the techniques of BA work because they are exactly those of due diligence. Sometimes we say that BA is just common sense, then laugh when we realize how uncommon it is. Due diligence IS common sense. Surely no one objects to due diligence? Indeed, why should anyone be concerned about the rise of due diligence? Isn’t that for dullards?

Before anyone spends millions of dollars (or even thousands), or takes any risk of consequence, it pays to do some amount of homework. If the homework seems overwhelming, expensive, or incomprehensible, that just means that the first 10 hours of homework are VERY important. They may be even MORE important than the next 100, or even 1000 hours. There is a LOT of earned value in doing ANY thinking versus none. Once thinking gets to thousands of hours, there is increasing risk of ossification, and the benefits diminish. In spite of this, a common complaint is “We don’t have time for analysis,” as if none were better than too little.

A common project mistake is to assign too much earned value to development, and not enough to analysis. Million dollar mistakes rarely happen at the field definition level, and are typically easy to explain and correct. This is true in spite of the fact that a significant percentage of labor and time may be spent on field level issues, or other technical concerns. Most of the value and risk control in the project may go to the first hours of analysis, with the development being quite low risk, as the “big” problems are actually resolved. It pays to control costs with analysis, and does NOT pay to control it with code change control.

This seems obvious enough, but analysis is overlooked and under-respected on more than a few projects – witness the 35% success rate of projects!t is, in fact, overlooked by the society in general. My father was once a Quality Analyst for a bank. “What do you do?”, I asked? “I make people think.”, he said. “Thinking is painful, and left to themselves, many won’t do it.”

Hmmm. The problem is, that the lax attitude about thinking is due to the illusion that we understand something is so strong. “I’ve been doing this for years, I know what to do!” In effect, EVERYONE thinks they understand, therefore, there is no need for an analyst – no one is (admits to being) confused – that would be awkward, scary even. In my experience, EVERYONE thinks they are THE analyst. It is, apparently, a strong hero role, even if we are only legends in our own minds.

Think about George Washington, fighting a desperate and losing war with England. In the midst of his desperation, he invented enterprise analysis, from a sheer common sense need – “What does the continental army consist of, what is it not, and what can we do about it?” That is bravery, true action, in the face of seemingly insoluble problems.

Imagine making these decisions without a sense of the whole enterprise. Imagine making these decisions under illusions of how coherent the enterprise was, instead of basing them on the best intelligence available.

Imagine pushing resources around “just because you can”.

And if you want to imagine those things, just imagine working on any project for the last 100,000 years, because human nature is such that it prefers illusion to facts, egos to inventories and simplistic principles to problem solving. Our progress comes in spite of ourselves, because nature supports common sense, and punishes lack of care.

The saying that ” common sense is none too common,” applies especially to BA. BA is the refined, professional level, experience based, highly predictive form of common sense. BAs don’t cite common sense; they practice it. They practice it because they are willing to learn, and think, in spite of the petty discomforts.

An example of how rare common sense actually is: Everyone knows you have to think of your customers to have a successful product (at least everyone would select it correctly on a multiple choice test). In spite of this fact, IBM was able to release the PCjr, with no applications that anyone cared about. IBM followed this up by dissing any employees who pointed out the problem. IBM’s slow decline in the late 80s and early 90s was inevitable, and that IBM no longer exists.

Professional BAs really believe in practicing due diligence, because they have seen what happens when you don’t. They are not in denial, and not afraid of the truth. They believe it, and live it, where others don’t, for whatever reasons. YES, they can see the future, because they remember the past.

In a world where “doing it because you can” is the message from the top, it’s easy to abandon due diligence – the paychecks can flow for years sometimes. It is much harder to adopt the Quixotic position – things are worth saving, improving; the world deserves to be a better place.

Given the importance of systems to the state of the future world (identity systems, micro-cash, medical imaging, health management, internet security, etc.), does anyone doubt that they want BA to rise?

This is an important question, for the following critical, political reason: If BA represents stakeholder value, doesn’t that mean that the Project Manager actually reports to the BA, instead of the other way around? Why or why not? Don’t most PMs wish they had a better handle on the requirements before the deadlines and budgets are set? Stay tuned.

Our society has hardly started building systems. We have traffic managements systems to build that will save lives, medical management systems that will empower patients, and identity systems that benefit the users (us) as well as the implementors (them?).

If anyone is against BA, they are against common sense, stakeholder interests, due diligence, and successful outcomes for a democratic society. If you are out there, and don’t want to play, please stand up, so the rest of us can work around you.