Making Data Meaningful

The Key to Effective BI is Asking Questions

DennisFoster — Fri, 18 May 2012 14:10:12 +0000

The key to effective BI is asking questions that if answered correctly will make a difference, in this case, in people’s lives and safety.

One of my first BI projects was for the Butler County Engineers Office (BCEO). It was classic case of taking common sense to a new level with technology. Among other things, county engineers in Ohio determine how to apply the state highway funds to improve the state and county roads within their local jurisdiction. The idea was to plot the location of each auto accident and use BI technology to determine which road sections and intersections were the most dangerous. Once we identified the dangerous segments, further analysis would show the improvements that would make them safer.

When the project began, copies of the accident reports required for analysis were not available on line but only on paper. We built a Windows application get the key accident data into a database, and then we could tackle the real challenges of extracting the BI necessary to make decisions.

The first challenge was to resolve the different ways that the accident locations were reported; the reports recorded the accident locations as the distance to the nearest address or intersection. The data had to be converted to the distance in feet from the beginning of the road to match the way the state identified highway locations. This was a continuing challenge until GPS technology enabled the absolute positioning of the accident and road locations.

The first approach to analysis was to count the accidents within a certain range of an intersection, or within a certain range on a highway. Some of the road sections with multiple accidents turned out to be among the best safety engineered highways and intersections in the county. Data doesn’t lie, but it might be misinterpreted. The high accident sections that were well engineered also turned out to have the highest traffic volume.

A new dimension needed to be considered, traffic volume, and with it came another complication. An intersection with thousands of cars passing through it has several accidents a year. Does that fact make it dangerous? Should we expect an even higher accident rate? Probabilities based on very small samples are its own area of study. The Engineers went to nearby Miami University to consult with one of the professors who came up with the science to enable us to compare the number of accidents on high traffic urban sections with road sections in remote rural areas and determine which sections were the actually the most dangerous and required additional analysis.

The BI application identified one dangerous side road intersecting a highway with some interesting facts. The vast majority of accidents occurred during the day, with very few after dark. This brings us back to the importance of common sense. When the engineers went out to physically inspect the situation they could see that a rise in the road would hide the stop sign until it was too late to stop. The driver could avoid a crash with the high speed cross traffic if they knew the area and had begun to slow down before reaching the rise. But that did not explain the lack of accidents at night. One of the engineers returned that evening and as he approached the still hidden stop sign, he could see the headlights of the through traffic glowing behind the rise. He slowed down and stopped while the cross traffic cleared. Mystery solved.

BCEO began this BI project in the 1980s which would make it one of the early BI efforts. My role several years ago was to migrate the app from a legacy DBMS to a MS SQL Server application with a web based user interface. From its beginning this accident analysis software has had all of the elements of today’s BI applications. Identify the information that is needed to make a decision, assemble the data required to support the analysis, apply the analytics to the data, and finally report the results. Greg Wilkins, the current Butler County Engineer continues to use this BI application to guide the decisions on how millions of dollars in road improvements will be spent to keep Butler County roads as safe as possible.

Organizing Large Projects – How to Avoid “Death by Meeting”

BillKamm — Tue, 01 May 2012 13:14:18 +0000

When I first heard the expression “Death by Meeting”, I thought it was the latest Stephen King novel, but after being the project manager of a project where I was expected to be involved in 20 meetings per week, dying seemed like a welcome alternative. You can avoid this slow, painful death by creating a project structure that focuses efforts and communications and reduces meetings.

In addition to the typical project management issues associated with the multitude of tasks required for large projects, there is a significant challenge in creating an efficient, effective project structure that drives the project effort to the correct worker-bee level and enables good project status communications, but streamlines the number of meetings required to achieve these goals. One approach that has worked for me is the use of Project Workgroups.

Most large projects consist of numerous tasks that can usually be grouped together in some manner. These groupings may be by departmental function (Finance, IT, Purchasing, etc.) by activity (sales, development, implementation, training, etc.), by deliverable (software release, management reporting, etc.), or perhaps some other logical division. Regardless of the grouping, there will be common goals and activities that will enable creation of workgroups reflecting these goals.

Once you have determined some logical workgroups, the next step is to define a project team structure. At the top of the structure is the Steering Committee. This is the group that is made up of senior management who are the key stakeholders for the project. The role of this group is to provide high-level direction, provide resources (monetary and personnel), and resolve major roadblocks to the success of the project. Steering Committees may oversee multiple concurrent projects, and will meet on a monthly or quarterly basis.

At this level, the Steering Committee members want to know where the project stands in terms of schedule, budget, and final deliverables. A fantastic tool for providing the Steering Committee this information is via a project dashboard. This dashboard should consist of a few key measurements with a status of each, using easy-to-read indicators like traffic lights or gauges. Here is an example:

This dashboard eliminates the need for developing voluminous detailed reports, and provides for exception level discussions. Only items that are yellow or red require explanation, so meetings are focused and their lengths are minimized.

The next level down from the Steering Committee is the Project Management Team, sometimes referred to as the Project Core Team. This team consists of key middle-management personnel representative of the primary functional areas affected by the project. The Core team should meet weekly or bi-weekly and is responsible for the direct management of the project activities. The RAID (Risks, Action Items, Issues, Decisions) document I referenced in my previous blog is the perfect communications tool for the Core Team. It provides a clear, concise mechanism for letting the team members see the critical items that require their attention.

The next level of the project organization below the Project Core Team contains the working groups for the project. The makeup of the workgroups will vary by project; however, this is the level where the daily tasks of the project are managed. This is the level that can bring you closest to a near-death experience since the number of teams and meetings is highest here.

Analyze your project and its deliverables to determine the best method for defining the workgroups. An excellent place to start is with the desired deliverables since it is difficult to split a single deliverable across workgroups. Another factor to consider is inter-departmental dependencies. Departments that closely interact with each other and/or are dependent upon each other can be combined on a workgroup to leverage that interdependency.

Meetings at this level of the project team need to be at least weekly. As above, the RAID document can be used to focus and track activities of the group, and facilitate communications to the project manager and the Project Core Team. If the tracking and reporting mechanism is standardized, then the project manager does not have to participate in all of these meetings. Focus the workgroups on the RAID documents and they will drive the agendas and reports so that meeting death takes a holiday!

In summary, to avoid the prospect of having the next project you manage being the planning of your own funeral after a painful “death by meeting” experience, try using the techniques described in this article. By constructing a project team structure as described, you can keep all the affected parties updated, involved, and focused in a manner that streamlines communications, maximizes resources, and minimizes wasteful meetings. The use of standardized task tracking and reporting tools will enable you as project manager to have visibility of all the project workgroups’ activities, and provide you the tools necessary to drive the project home successfully.

Day to Day Data

nickbikas — Wed, 25 Apr 2012 14:46:05 +0000

As the evening winds down every night, I like to look back and reflect on the day’s events. Being an analytically minded person, I tend to look back at decisions that were made and how they had an effect on events that transpired throughout the day. As I delved into this nightly process, I started looking at the day in a more granular manner. Upon doing so, I came to the realization that we are all swimming in “Day to Day Data”.

Did I run out of coffee this morning? What time did I get in the car? Are these are completely unrelated items of information? If you answered no, then I would be inclined to say you are wrong. All these granular pieces of information are important to someone or some entity. Tell McDonalds the answer to these two questions, and they have the perfect time to run an ad on the radio for their “premium roast” coffee.

Take time to think about your day to day data. Think of all the pieces of information that drive your day; you can use this information to accomplish a great number of things. Identify inefficiencies that are a constant annoyance.

The day to day data that we create is astounding. As we all know now, the data is out there. The data is important but what is more important is identifying what information is vital and to whom. Data can be helpful, but it can also be stressful. Data is the figurative key that can open the door to future success but what if someone handed you the keys to the entire building instead of the room you want. How do you find the right key? It is important to have help to identify which (if any) of those keys is useful. That way you can make your Day to Day Data Meaningful.

Does Your Data Keep You Up At Night?

Christie Bautch — Tue, 27 Mar 2012 18:35:38 +0000

I recently purchased a new car and the process clearly took longer than it needed to. I am not a person that is typically prone to long-drawn out decisions, so I began wondering why this one decision took so much longer than previous car purchasing decisions.

I reflected upon one of my earlier car purchases (back in 1997) as a comparison. When I purchased this car, the process was fairly straight forward. I drove to a few local dealerships and browsed the showroom until I saw something in my price range that caught my eye. Over the course of several weeks, I test drove several cars and talked with family/friends/co-workers to see if anyone had any input on the reliability of the vehicles. Quickly, I narrowed it down to one vehicle. I didn’t lose any sleep thinking about the decision. I just went with my “gut feel” and stayed within my budget. I was very happy with my purchase and kept the car for 140,000 miles.

With the most recent car purchase, the process seemed to take on a life of its own. I had so much information available to me that I spent months researching cars using every automobile search engine and consumer report that I could find. I often used my SmartPhone to identify nearby car dealerships just so I could do “drive-bys” and look at cars. Each car I researched had so much positive and negative input available that it became overwhelming as to what was the “right choice”. I have to admit that I had so much information coming at me that I started dreaming of cars at night and often awakened in the morning with cars as the first thought on my mind. I had clearly found myself with information overload and was in “analysis paralysis”.

I’ve seen this happen in business too. There is so much data and information available at every turn that it is hard for Business Leaders to weed through what is truly relevant and what is just “noise” getting in the way of making the decisions needed to move the business forward.

If we want to keep our business from getting stuck in “analysis paralysis” – we need to identify what information is truly necessary for us to achieve our business goals and implement the correct tools to visually present this data in a way that facilitates our decisions and doesn’t hinder them. The challenge is determining what data is meaningful to the decisions that need to be made.

To have effective Business Analytics, the business goals must be clear. If the data you are looking at doesn’t help you make decisions to achieve these goals, then this data may be just “noise”. How much data do you look at each day that really isn’t helping you achieve your goals?

If your data is keeping you up at night, maybe you have too much of it.

The True Value of Agile…Don’t Point Fingers!

DRobinson — Fri, 23 Mar 2012 15:12:05 +0000

In my previous post, I proposed that the True Value of Agile is derived from fostering an environment of Continuous Improvement through Communication and Collaboration. To be sure, Communication and Collaboration alone will not bring success. As Vin D’Amico (www.brainslink.com) commented, a critical component to Agile Value and success is a shift in corporate culture to support an environment that encourages risk taking and refrains from seeking to assign blame on any individual when things go awry. The challenge here is that this goes against most traditional Western, and Asian, cultures for that matter. In order to improve we must identify what we do well as well as what needs to be addressed. Sometimes finding a better way requires taking the risk to do something no one has thought of before. That does not always lead to success; however, it provides an opportunity for learning and growth. In “Agile,” teams we do not work and make decisions in isolation only to be the single “neck in the noose.” To be an effective Agile team there is no “You” and there is no “Me”, and definitely no “Them.” To be successful the group must live and die as a team.

I am not suggesting Agile teams are like hippie communes, but there are similarities (remember that Steve Jobs lived in a commune before his 15 minutes of fame). Everyone works for the greater good, which is moving the product forward and delivering business value. There is much work to be done and defined timeframes in which to do it. We have tools, and skills, and ideas about how best to complete those tasks. We are jacks of all trades and masters of a few, not one. Effective agile development teams are made up of generalizing specialists. It is this cross-training that helps mitigate singled threaded development as well as unforeseen events that may remove someone from the team for a period of time such as attrition or illness. Once we have our list of work items, which becomes our product backlog, we are able to self-select which tasks we can commit to completing. This is another shift in culture. Traditionally, work is assigned by management to the individual specialists. In an Agile culture the people performing the work are trusted to know best how to distribute the load so that they can successfully meet their commitments and provide value quickly. There should always be something for everyone to do to move forward. To this end, no one should be waiting for work.

We are not alone in our agile commune either. The business product owner is there with us, every day, to prioritize and test, and yes, re-prioritize and add or defer features based on our velocity and changes in scope. This is not normal for the business owner in relationship to traditional requirements planning for software development. The scrum master, our servant leader, is also with the team, every day, to work with the product owner to find the most valuable work that can be reasonably fit into the sprint. The scrum master is a servant leader in that it is this role that both serves the needs of the development team to remove obstacles, and provide whatever is necessary for the team to be successful and at the same time leads the team by working as a bridge between the product owner and the team, working on the backlog and the schedule. The dynamic is not unlike an orchestra. The Product Owner is the composer. The scrum master is the conductor, and the members of the development team are the musicians.

What I have described is contrary to most traditional organizations where the business and IT only communicate at the beginning and the end of the project, where divided IT teams are comprised of specialists like a relay team that wait on each other to pass the baton. We need to be more like a volleyball team who work together and support each other to move that ball over the net in the most effective way possible.

Changing corporate culture where failure is treated as a cardinal sin to one where it is addressed, reviewed and used as a learning point is challenging and requires buy-in from all levels of the organization. These concepts are taught in Agile training courses; however, they are not often embraced and supported by corporate management culture. The folks sent to class are typically the developers and the project managers, but rarely the upper management and business sponsors that play a key role in making “Agile” successful.

To achieve the true value of agile we must all work together for the greater good of the company by creating and supporting a nurturing environment of continuous improvement and stop pointing fingers.

Who Killed ‘My Favorite’ Project?

SusanThomas — Mon, 12 Mar 2012 17:36:48 +0000

In the not too distant past, My Favorite Company, embarked on My Favorite Project to revolutionize My Favorite Industry and leave competitors in the dust. When competitors got wind of this plan, mysterious things started to happen. And before too long, mysterious turned to sinister. Then one day, My Favorite Project was found terminated. How could this happen? Who would do such a thing? A special task force was commissioned to investigate. Who killed ‘My Favorite’ project? You decide.

Victim: ‘My Favorite’ Project

Injuries: Depleted budget, fractured Scope, and fatal hit to Quality

Description of the Suspects: Project Manager

The Project Manager was assigned to achieve the project objectives by understanding and applying tools and techniques to manage the project including the authority to approve certain types of change requests as defined the project’s roles and responsibilities.

The Project Manager was diligent about identifying project objectives, addressing the various concerns and expectations of the Stakeholders and balancing the project constraints including: scope, quality, schedule, budget resources and risks. Because of the potential for change, the Project Manager crafted a plan that was iterative and went thru progressive elaboration throughout the project’s lifecycle which allowed for continuously improving and detailing a plan as more specific information and more accurate estimates became available.

Software Product Manager

The Software Product Manager’s main role was representing the product to the customer. The Software Product Manager investigated, selected, and developed the products for the organization, performing the activities of product management at all stages of the product lifecycle. (Note: The four main stages of a product’s life cycle are: 1) Market introduction stage, 2) Growth stage, 3) Maturity stage, 4) Saturation and decline stage.)

The Software Product Manager was also responsible for gathering software requirements using a Marketing Requirements Document (MRD) developed by the product planning/marketing team, and developing a high level Product Requirements Document (PRD). In addition, the Software Product Manager created an elaborate Software Requirements Specification (SRS) for the software engineering/development organization for subsequent design, development, and testing activities. Lastly, the Software Product Manager created User Acceptance Test (UAT) procedures, facilitated UAT sessions with end-users, and ensured that the product met the specifications and that it was deployed successfully.

Possible Motives/Scenarios:

1) The development of a product was a project on its own

2) Or, an existing product might have benefited from a project to add new functions or features

3) Or a project might have been created to develop a new model

Clue1: The product lifecycle consists of generally sequential, non-overlapping product phases determined by the needs of the organization. The last product lifecycle phase for a product is generally the product’s retirement. Project lifecycles on the other hand, occur in one or more phases of a product lifecycle. All projects have a purpose, but in those cases where the objective is a service or result, there may be a lifecycle for the service, not a product lifecycle.

Clue2: The project lifecycle is a collection of generally sequential and sometimes overlapping phases determined by the management and control needs of the organization. While every project has a defined start and end, the specific deliverables and activities that take place will vary widely with the project. The project life cycle provides the basic framework for managing the project, regardless of the specific work involved.

Hint: Many facets of the product life cycle lend themselves to be run as projects (e.g. performing a feasibility study, conducting market research, installing a product). In each of these examples, the project life cycle would differ from the product lifecycle. Did the Product and Project Managers have different agendas? Did the two not make it clear who was driving My Favorite Project? Or did the two simply not communicate, which dealt the fatal blow?

Who Dun it?

The Jury is out for deliberation.

You decide.

MicroStrategy – Have you looked at THEM lately?

Jonathan Shirey — Fri, 09 Mar 2012 15:46:18 +0000

If you haven’t done so lately, it’s time to take another look at MicroStrategy. They have done a great job in updating their offerings to match what is currently hot in the marketplace. They couple eloquently form and function together to please customers and technicians. You are sure to find interesting and thought provoking content within their product offerings. And you might even find things that have personal application as well as business application.

Here are the latest focus points in their strategy:

MicroStrategy Cloud Intelligence

One of the pillars MicroStrategy is focusing on is Cloud Intelligence. The details about the structure and function of the cloud are easy to understand. It is a seamless fit into the Microstrategy BI environment. After an initial perusal of the offering, it is easy to see the power, flexibility, and security of cloud computing, and how one is able to utilize it to drive their business decisions and adoption within organizations. MicroStrategy has gone to great lengths to highlight the advantages, the steps necessary to setup and deploy, and as a result benefit from the MicroStrategy Cloud. I believe this is a special niche that those who can visualize how to ramp up business intelligence projects without a lot of the normal overhead of software/hardware procurement as part of projects. One is left to focus on what they do best, and leverage an optimized platform as part of the overall deliverable.

MicroStrategy Mobile Intelligence

Microstrategy has bet the business to emphasize the importance of mobile intelligence. They believe that it will overtake the traditional web browser based intelligence that is prevalent today. MicroStrategy focuses on educating the business and developer community about the value of the MicroStrategy Mobile platform. It is easy to gain access to learn how to use the MicroStrategy platform to design, build out, maintain, support, and customize visually enticing apps for multiple output devices (iPad, iPhone), while leveraging the enterprise-caliber features of the MicroStrategy BI platform. This is achieved by implementing the metadata layer that governs all content. Highlighting such functionality, it helps to show that MicroStrategy is clearly the market leader within this pillar and there were customer stories to back up this claim.

MicroStrategy Social Intelligence

This is the most unusually interesting pillar due to the cutting edge nature of it. MicroStrategy Social Intelligence solutions is designed for both commercial customers and the consumer in the marketplace. MicroStrategy has built a bridge between the two that is compelling and an opportunity for those that have the courage to leverage it. MicroStrategy latest offerings that enable in-depth analysis of the Facebook fan base. They also focused on how to apply the research in the wealth of information available at Facebook to deliver very effective marketing campaigns, which basically makes the older style CRM systems obsolete. MicroStrategy walked through the steps and their products that help make this happen, which turn the promise of social media content into real business opportunities. Once engaged, a loyal fan-base turns into revenue… and companies that understand this and who those customers are, they will achieve a competitive advantage.

MicroStrategy Big Data

Big Data is here now. MicroStrategy has methods and technology that help clients deal with the extreme data volumes. The point was made that companies need to have the ability to use very large databases and data sets to make intelligent business decisions to drive growth and gain competitive advantages. Often interesting information is lurking in the details and MicroStrategy provides a method to make sense of it. MicroStrategy also offer features such as improved self-service that reduces the reliance on IT, when it comes to navigating the business intelligence architecture. There is even the possibility to connect MicroStrategy to Hadoop and begin to analyze web logs in a very easy to consume fashion. In addition, MicroStrategy focused on high performance across the entire platform to eliminate latency issues and meet performance goals.

The time is now to take a fresh look at Microstrategy. They are a big time player in the tools space to enable Business Intelligence. You won’t regret it.

The Business Intelligence Partnership – A Key to Success

WendyWilson — Fri, 09 Mar 2012 15:30:33 +0000

“It takes two to tango.”

“There is no “i” in Team.”

“The sum is greater than the parts.”

There are so many sayings that capture the importance of team work. Whether it’s a dance or a sports team, success is often found when team members have a symbiotic relationship; one can’t be successful without the other. Business Intelligence programs are no different. They, too, require a team effort or partnership to be successful. That partnership is between the business and the technology functions of a company.

While IT departments are accustomed to working with business associates for application development purposes, the relationship in a BI program is different.

Application development is mostly focused on delivering a transactional system that is rooted in functional requirements. Requirements are generally known upfront, detailed, and static for the foreseeable future. Interaction between the business stakeholder and the IT development team is likely intermittent and as needed. Once the application is developed, the project ends and any temporary team is disbanded.

By contrast, business intelligence really never ends. BI exists to meet the ever changing analytical needs of the business. As a result, a dedicated joint business and IT team, often referred to as a BI Competency Center (BICC), is usually formed to meet those needs. The BICC team is long-lived with ongoing responsibilities to deliver reliable data and meaningful analytics. Business questions that likely drive requirements are not usually fully known upfront and will come to light through joint prototyping and iterative development. Additionally, a BI program will have multiple iterations or development projects underway at once. Therefore, interaction between the business and IT components of the team is likely to occur on a daily basis. Because business intelligence is often an enterprise wide, strategic initiative, the BICC is ideally led by an executive sponsorship committee jointly comprised of business and IT leaders.

The interdependency of business and IT in a BI program starts from the very beginning and continues through all functions of the BICC. For example, establishing an over-arching BI strategy and designing the blue print for the related architecture requires the business members to articulate the company’s strategic direction, how it operates and the relationships in the data, their analytical needs, the timeliness of the analysis, etc. This enables the technology side of the team to design the architecture, recommend proper tools, and design databases that best support the needs of the business.

Another example is the process to manage the company’s demand for BI. While the business members of the team will likely collect, inventory and assess the benefit of the ever changing needs of the company, the IT side of the team will provide input to a cost and effort analysis which will help to jointly prioritize the iterative development.

Joint participation is especially apparent in one of the core functions of the BICC, which is to manage the data as a strategic asset. Data governance is all about managing the data assets to ensure integrity, usability, accessibility and security. It ensures the right data is available at the right time so that informed decisions can be made based upon reliable data. Data governance focuses on managing data quality, master data and metadata. In each of these areas, the business and IT members of the BICC work together to define, measure, cleanse, and publish necessary information to ensure the data is consistent, understood, reliable, and has relevant business context. Usually, specific processes and tools are implemented to govern the data.

The joint partnership between the business and IT is one of the keys to a successful BI program. Working via a long term, valued added relationship brings many benefits. The business and IT components of the BICC will consistently drive toward the same goals, speak the same language, better understand and even anticipate each other’s needs, respect and leverage each other’s talents, gain momentum faster, and produce a better product overall. Just like the dance “The Tango”, in the world of BI, it takes two to be successful.

The True Value of Agile

DRobinson — Tue, 06 Mar 2012 15:16:51 +0000

I recently attended an event on Agile Business Intelligence. One of the speakers made the statement that the core value of “Agile” is to be faster and cheaper. On the surface you may say, “Of course. We need to deliver value faster and spend less doing it.” Accelerated delivery of value and reduction in cost are the results of being Agile but not the true value.

I propose that the answer is more esoteric and suggest that the true value of Agile lies in the path the people involved follow to reach the state of rapid lower cost delivery. The goal of applying Agile principles should be to create an environment of continuous improvement.

So, what are these principles and how do they help to foster such an environment? The core principles of the Agile Development Methodology are stated in the Agile Manifesto established in February 2001 in the mountains of Utah.

I believe the most important tenets of Agile for Business Intelligence lie in the aspects of Communication, Collaboration, and the willingness to embrace change. There are practices and tools such as Test Driven Development and Continuous Integration that will help to improve the speed and quality of the work we are delivering; but, tools alone will not make us successful. The path to Agility is not a short walk. There are challenges to overcome, both organizationally and personally for each member of the team, business and IT alike.

The first stop on the path to improvement is communication. Communication between the business and IT, between members of the development team, between executive management and front line management; fundamentally, between everyone who contributes or benefits from the work we are doing.

The first point of communication is the understanding of requirements. This does not just mean “what” we are going to deliver, but also “why” it is needed, “how” we are going to test it to make sure we did it right , “what” value it brings to the business, “how” we are going to measure that value, and “what” decisions we are going to make now that we have it. All of this information is gathered through a dialogue, a conversation that elicits questions and reflection which drives to a better understanding of the need. It is during these conversations that the requests must to be broken down into manageable units of value that can be successfully delivered in short 2 to 4 week intervals. This is a paradigm shift for most traditional organizations in that the business must learn to embrace receiving small incremental value versus waiting for everything to be completed. For example, the end goal may be to create a Management Dashboard composed of multiple pages of gauges and charts. The business may say “I need it all or it isn’t useful;” however, having one or two of the reports may provide some immediate value and again elicit more dialogue about the true needs. Perhaps the format isn’t quite what the business wanted or perhaps there are alternative contexts in which to view the data that we didn’t consider during the initial discussions. It is also possible that there was an expansion in a line of business or a new distribution channel that may impact what data needs to be captured and displayed.

By keeping the lines of communication fluid, changes will be identified quickly so that needs can be met and true value can be achieved.

Revisiting the presenter’s comment that the true value of Agile is “Cheaper, Faster”, it is my opinion that communication is foundational to achieving efficient and timely delivery of success.

Now that we know what to build, we must explore how best, we as a team can build it. In my next posting I will discuss the Agile development team dynamic.

Project Management – Critical Success Factors for Consultants

BillKamm — Tue, 06 Mar 2012 14:09:05 +0000

Project Management can be intimidating for internal project managers, but for an external consultant the challenges are amplified. In addition to the typical responsibilities of defining tasks, resources, durations and dependencies, consultants also must address client policies, procedures, organizational structures, and the ever-present internal politics, while remaining focused on the project deliverables.

The following provides some suggestions for achieving success as a consultant project manager.

Organization

- Every organization considers themselves unique and different. It is critical for you to understand what makes this specific entity different in their eyes. It might be the organizational structure, their culture, or their operating philosophy. A good place to start your search for these answers is to review the company’s annual report and/or its website. Look for their Mission Statement, Investor Relations, Company History, and Goals & Objectives. If at all possible, you should do this research before your first day at the client

Project Sponsorship

- When you start any consulting assignment, it is imperative to identify the key individual who is responsible for you being there. This person may not always be the project sponsor, so you need to take the additional step of determining who has the final decision-making authority for the project and introducing yourself to them. This person is typically at an executive level, so getting an audience may be difficult. Ask for the meeting by providing a clear objective to the sponsor. For example, “I would like 15 minutes of your time to introduce myself and discuss your specific goals for the project including how you would like me to communicate with you going forward.”

Project Team

- The odds are good that you will not be the only resource working on the project. How you manage the pool of resources that is available to the project is arguably the most challenging aspect of project management. They normally have full-time jobs, and the project work only adds to their workload. They also possess the expertise and skills necessary for project success, or at least their management thinks they should or they wouldn’t be assigned to the project. As project manager, you are expected to make this group of individuals into a team with a focus on achieving the project goals, but as an outside consultant, you will not have any context from which to determine a person’s capabilities or performance. An excellent way to assess the available talent is to have them provide input into the detailed project plan. I will explain how to do this in more detail in the “Project Methodology” section below, but people will typically perform at a higher level when they not only understand the goals, but have helped to define what needs to be done to achieve those goals. If some tells you what, when, and how they are going to do something, they will feel a sense of ownership much more than if someone else just tells them what to do.

Project Communications

- There is a myriad of tools available to manage a project. The most common is Microsoft Project, which contains all the functions needed to manage a typical project. While I strongly recommend developing an expertise in MS Project, I have also found this tool can be overwhelming for non project managers. Just because you need a good project management tool to do your job, don’t force it upon everyone else involved. As indicated above, you should already know what your Project Sponsor is looking for in terms of communications, but also find out what the management team and the project members want in terms of details and determine what the organization uses for these types of communications. It may be Excel, Word, or maybe even just email. Whatever it is, use it! You should structure your project using phases, summary tasks and milestones so you can easily report at the level of detail needed. I have found a simple Excel file with four spreadsheets in it is a great way to communicate key project items. The document is called a RAID. This is an acronym for the four sheets: Risks, Action Items, Issues, Decisions. The actions items come straight from the project plan, but lists only key tasks in the period being reported. The risks, issues, and decisions tabs provide a historical record of those key areas that make or break any project. Whether you use Excel as I do, or some other tool, these four sections are important ones to communicate.

Project Methodology

- If you have taken all the above steps you are well on your way to being a successful project manager, but there is one last area that pulls all this together: the methodology you use to define and manage the project. I am a strong proponent of having an involved project team. The best way to get and keep people involved is to provide an environment that fosters participation, ownership, and responsibility. Here is an approach that has served me very well:

Clearly define the project goals. (Remember your meeting with the project sponsor?)
Gather the management team and define key project milestones and resources.
Invite the project team to a kick-off meeting where you should explain the goals and the key milestones, and use this meeting to define the key tasks necessary to achieve each milestone. Once a task is defined, ask who should perform the task. As the group dynamics take effect, it will be easy to identify the leaders, the followers, the supporters, and the detractors.
After the kick-off meeting, publish the basis task plan showing the key milestones with the tasks and resources supporting each to the project team. Ask each person to provide a time estimate for each of their tasks, and a list of what they need in order to complete them.
Once you have the above information, you have everything you need to develop your detailed project plan with resource assignments, durations and dependencies. If you use MS Project, gaps and conflicts will be easy to identify and address.
Now you can publish the detailed project plan to your team for final review before it goes out to the management team.

As a Consultant Project manager, you may face some additional challenges, but I trust that the above is useful in helping you to overcome them and keep you on track for achieving customer success.