Tag: Team

Six Attributes of Leadership

Written by Cynthia Low on November 17, 2008. Posted in Articles. 1 Comment on Six Attributes of Leadership

Does leadership have an effect on project success? Is there a difference between management and leadership? Can leadership be learned? The answer to all these questions is yes. In this article, I will look at six attributes of project leadership. This is certainly not a complete list, just a start. One that I believe can help project managers achieve project success.

1. Think Laterally

The first attribute, lateral thinking covers a variety of methods to get us out of the usual line of thought. It is this kind of thinking that cuts across the instilled and predetermined patterns we all too often employ when working on a problem. With this type of thinking we try different perceptions, different concepts, and different points of entry and consider multiple possibilities and approaches instead of a single approach. Many problems we face as business analysts and project managers require different perspectives to solve them successfully.

2. Empower the Team

Often, there is little or no recognition for people who spend time on elementary problems, it’s the big problems that receive all the attention, yet, big problems start as minor problems. All too often, because of leadership attitudes, employees develop the habit of ignoring problems until they explode, at which time they become big problems, then leaders want to go on record for being a problem solver. Empowered project teams correct this attitude. They focus on getting the job done while solving or preventing problems while the problems are still minor.

The ultimate paradox of project leadership power is that to be an effective leader, one must turn all team members into leaders. In this way, processes such as relationships and the issues of leadership and empowerment become important. Successful leaders are able to motivate, to energize and to empower others. When people are excited and empowered, it affects both their task initiation and task persistence. That is, empowered people get more involved, take on more difficult situations, and act more confidently. Empowered people expend more effort on a given task and are more persistent in their efforts.

3. Be Optimistic

The third attribute is optimism. Leaders are optimistic. They think positively. Positive thinking is more than just avoiding negative emotions; there are actions and forethought involved. When negative events happen, excellent project leaders purposefully look for something positive. Instead of feeling that they can’t do something, they look at the problem as an opportunity for themselves, the project team, team development, bonding and growth.

4. Demand Better

On-going self-assessment and self-evaluation are critical for ensuring that your project is meeting its objectives and having a positive impact. Demanding better is actually a simple idea. All one has to do is ask, “What can we do even better?” Essentially that’s all there is to it. Asking the question over and over again focuses leaders on challenging themselves and team members. Further, it sets into motion an on-going self-evaluation and a focus on the process of achievement. In return, this focus on the process brings results.

5. Encourage Delegation

Delegation is one of the most important roles of your job; as a leader your job isn’t ‘to do, it is to gain or accomplish things through your team members. Your time should be spent on such things as visioning, motivating, controlling and goal setting, and not on trivial jobs such as fighting fires or responding to interruptions and correcting errors.

Delegating relieves time-pressures on you. It provides your team members with an opportunity to expand their own skills in decision making and problem solving and encourages their creativity and initiative, while motivating them to become what they are capable of being.

It forces you to spend time with your team members, thus developing your interpersonal relationships. Your feedback and attention will encourage them on to greater things. It helps set performance standards based on member’s accomplishments or results, rather than purely on their activity. It helps to increase results by releasing you from some of your activities. You will be able to step back and look at the bigger picture instead of being caught up in the internal activities of the project. You will be able to think outwards for the better of the organization and not lose sight of the real goals.

6. Reside in the Future

To meet future challenges, leaders must reside in the future. Only then can they set a vision with reasonable goals and promote the process of developing effective strategies to achieve them. Considering the future enables leaders to think constructively about it, and do the things that contribute to achieving their visions. Proactive future oriented thinking can lead to greater project success. The future will happen, no matter what we do. If you want a successful future, you need to work at it.

Victor Teplitzky is a Principal Consultant at Advanced Management Services, Inc. (AMS), a full service management consultancy servicing an international client base. Victor is an Industrial Engineer and Behavioral Scientist (HRD/OD). Since 1974 he has provided training, consulting and assessment services to a wide variety of organizations in both the public and private sectors including; the National Guard, US Postal Service, National Institutes of Health, Sara Lee Corporation, DoE, DoD, GPO, USACE, FAA, Wal-Mart, The Hartford, ING and many more Fortune 100 and Global 2000 companies. Victor has designed and developed over 100 training workshops including both general programs for “off the shelf” presentations and workshops tailored to meet specific client needs in the areas of Project Management, Business Analysis, Professional Development and Business Development.

Defining Requirements within a Short Time Frame

Written by Cynthia Low on October 15, 2008. Posted in Articles. 3 Comments on Defining Requirements within a Short Time Frame

Recent industry studies show that modern software projects on average spend 40 percent of their effort on rework. As a result, over 60 percent of software projects overrun budgets, miss schedules and substantially reduce delivered functionality. Without a clear idea of how to set requirements, most software development projects will face either significant rework or fail altogether. Over the past few years, Agile methodologies appear to be helping reduce this problem. This whitepaper will explore techniques of capturing requirements within Agile teams.

Wikipedia says that, “The term Agile Software Development refers to a group of software development methodologies that promotes development iterations, open collaboration, and process adaptability throughout the life-cycle of the project.”

So, if we apply a sports analogy, using Agile methods to develop software is like a series of sprint races. Developers are focused solely on successfully completing the next iteration, which is often due within a matter of weeks, and they zero in on defining their requirements to achieve that short-term goal.

In other words, Agile teams don’t produce any requirements specifications that are not absolutely critical to making it clear to the team what is expected of them in the short term. So, the question becomes: How do you decide what requirements are “just enough” to complete the next iteration?

There are a number of factors that need to be considered, when deciding what techniques and how much level of detail to provide when defining requirements for an Agile team. These considerations should include:

Team size and the proximity of team members
Skill and experience of the team
Has the team worked together before?
Complexity of the requirements
Complexity of the software.

Keeping the above considerations in mind, you will need to decide which techniques you will want to use and how much detail you will want to provide while using these techniques.

Common techniques include:

Verbal Communications. Verbal communications, perhaps using a whiteboard to capture key thoughts, is typically the fastest way to define a requirement. However, what this approach makes up for in initial speed, it doesn’t ensure that all stakeholders are in the loop. Plus, participants may not all remember exactly what was decided after the meeting breaks up. It is all too easy to have a different recollection of details that were discussed two weeks ago. This can lead to misunderstanding of requirements during development and testing, and will be reflected in inaccurate product user guides and training material. So you may have saved time initially, but wasted more time in the long run.

So when is verbal better than written communication? Agile methods promote face-to-face interactions, but that can be impractical in cases where teams are scattered across the globe or even across a city. Relying only on verbal communications is a last resort, to be used only when short-term time gains are worth more than the longer term problems this approach can create.

Story Cards. A popular and valuable technique within Agile development teams is to create a story card. These story cards tend to provide a text-based description of who wants to do what and why, along with perhaps a picture of the screen and some test scenarios. This technique works well for very small features but may not scale well for larger or more complex features that integrate and depend on other features.

Requirements Lists. Often a common place to start from a product scoping point of view is to create a hierarchical “Requirements List” which captures in text form an organized and grouped list of functional requirements, technical requirements, business drivers etc. Often these text descriptions can be enough to clearly articulate what the requirement is For example a technical requirement such as, “The application must support IE 6 and IE 7,” does not really need any additional explanation. However a requirement such as “The application must be able to define which users can have access to specific functionality and data” will need much more detail. The point is to only expand on requirements that truly need more details.

Use-Case Flows. Sometimes to truly understand the overall flow of a more complex requirement use-case flows or simulations are required to capture “just enough” requirements. However from my point of view it typically is not a good idea to use “use cases” to document complex logic or business rules such as authorization logic. These types of requirements are often better documented in text or tabular formats. For example, a simple 2×2 table showing the roles on one axis and what they can do on the other axis is a much more efficient way to convey authorization business rules than embedding alternate flows into use cases.

Simulations. Simulations can add great value to really bring a concept to life, but adding every single detail into the simulation can take too much time. And, frankly, it is sometimes difficult for developers to reverse-engineer a simulation and extract a discrete set of requirements. It is much easier for an Agile team member to read a simple table showing who can do what, than to run through a simulation and reverse-engineer the same information. Also, it is possible to spend too much time doing elaborate simulations that don’t add enough value for the time and effort they can take to develop.

Everyone will have their personal preference as to when to use what technique for communicating requirements, but the key is for the team to work together and agree upon when it makes sense to use different techniques and not “force” a technique when it clearly can be done more easily another way.

General Repository. No matter what techniques you decide to use to document requirements, keeping these requirements details/artifacts in a central repository and linking them to each other in an organized manner is critical to the collective success of your Agile team. Relying on people to keep track of endless email trails and simple document repositories with manually maintained links is not the answer. People are too busy to do it, and, most likely, the data repositories will not be kept up-to-date. Because of that, any repository needs to do whenever possible to automatically create and maintain these links based on how the artifacts are organized. For example, if a use case refers to a screen on a given step, then that screen should be automatically linked to that step in the repository.

So how do you know what is enough detail? Your team will let you know when things require more details. Part of working within an Agile team is to expect the need for requirements clarification throughout the project. In traditional waterfall, this was almost discouraged and under the good intentions of change management. However, within Agile, it is expected and embraced, which takes some getting used to for Agile newbies.

Recap

This topic is much deeper than can be covered with this small article, but the key points are

Make a conscious decision on the level of detail you want but expect to tweak that during development.
Choose the right technique for the requirement you are trying to describe.
Make sure you keep an integrated central repository that links together the multiple requirements artifacts.

Martin Crisp is CTO of Blueprint Systems. He can be reached at [email protected]

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].