Velocity is not just for consultants
In our engagements at clients, we often get asked this simple question: how do your teams get so much done compared to my teams? In other words, how do you achieve the velocity that we aspire to in our internal IT organizations? Clients think they are doing the right things the right way, but at the end of the day, they see only nominal improvement in delivering their services to the business.
In this paper, we will share with you some of the common hurdles our clients face and the things they have done to overcome some of those hurdles. Additionally, we will discuss how you can apply these concepts to your own personal performance as you strive to maximize your contributions. We will also share with you some of the things we do at Pariveda Solutions that help to equip us to perform well in our client settings, often under greater scrutiny than the client IT organization because of the costs associated with using professional services firms.
We often get asked this simple question: how do your teams get so much done compared to my teams? In other words, how do you achieve the velocity—simply stated in this context “the pace at which work gets accomplished”—which we aspire to in our internal IT organizations?
At least in their minds, our clients are saying this: “We think we are doing the right things, or at least we are trying. We have scrums. We allocate time for project management efforts. We try to work closely with the business to keep our priorities in line. We have even hired more people. Yet at the end of the day, we are barely able to deliver enough output to mollify the business or ourselves.”
IT organizations face a number of challenges in achieving the velocity it desires and the business needs. Typical questions that our clients face are as follows:
- While often viewed as a cost to the business, and especially in light of the current economic conditions, IT continues to be challenged to do more with less
- IT organizations face the additional challenge that technology—that used by the business and that used within the realm of the IT organization—is moving faster than their people can keep up with
- Often, in order to obtain or sustain investment from the business, IT organizations pitch the expanded use of technology as the silver bullet to increase throughput
- IT organizations attempt to evolve its processes for managing its efforts—“waterfall”, RUP, Agile—in an attempt to ensure getting solutions done the right way
- Offshore enablement adds pressure to the combination of internal cost versus throughput arguments
- Business needs change rapidly accelerating the treadmill that IT is running on.
At the risk of giving away the keys to the kingdom, there are a number of areas (Exhibit 1) you should look at when considering steps to take to accelerate the contribution of IT to the goals of the business. The answer, or answers, to the simple question expressed initially in this paper can be fairly straightforward.
Exhibit 1 – Velocity Factors
Before approaching some specific questions, a foundation of business alignment is necessary to maximize velocity and strive for the benefit of a more fulfilling career experience by your team members. The next graphic (Exhibit 2) provides a template of components within an enterprise architecture framework can provide a roadmap for alignment.
Exhibit 2 – Enterprise Architecture Framework
In order to ensure that your teams have a clearly defined mission that is in support of the enterprise's mission, ask these questions:
- Is there executive alignment and sponsorship of IT within the enterprise?
- Is there regular review and refinement of IT execution against the enterprise goals?
- Are individual roles linked to the broader enterprise and IT organization objectives?
- Are individual/team tasks aligned with short-and long-term achievement expectations?
- Are metrics and frameworks defined for contribution by resource/role?
Answering these questions provide a baseline for aligning individuals and teams into a context allowing effective velocity. Once defined, you can then begin to look into detailed aspects of your IT function.
First, you should start by defining what the velocity goals are. Have you defined a strategy and established goals that are, at least to a certain extent, independent of the goals of the business? What type of strategy are you following—low cost, operational excellence, product innovation, or customer intimate? Each strategy comes with it some level of understanding of the type of velocity you should strive for.
When defining velocity you need to recognize the following:
- Velocity is rarely clearly defined or adequately measured
- Velocity, to be achieved, is a combination of how a variety of factors are addressed by the IT organization and supported, if not sponsored, by the broader enterprise
- Velocity is not a constant and will have its peaks and valleys.
Second, how engaged are your people in the success of the business? Particularly in younger and growing enterprises, are your people “all in”? If the answer is yes, then your people will be more likely to take the necessary steps to get work over the finish line on, or ahead of, plan. The steps we are referring to include prioritizing their time so that they do not let unrelated time demands distract them from the goal. Or they will put in that extra hour or two to finish today something they might otherwise put off until tomorrow. And probably most importantly, they will approach their duties with an internally born passion that serves as the impetus for doing what it takes to deliver.
Third, is the work environment conducive to efficient work delivery? One thing that corporate personnel face that consultants often do not is the propensity to be interrupted by routine corporate activities unrelated to a project or initiative—e.g., e-mails, ad-hoc meetings, benefits enrollment, backfilling for a peer on vacation, etc. Studies, depicted in the next graphic (Exhibit 3), have shown that people are most effective when they work alone yet this is the smallest share of their work time. So It is critical that employees maximize their productivity during this “alone” time.
Exhibit 3 – Developmer Time
During this single-minded time, people can achieve a state called flow. It takes 15 minutes or more of concentration to achieve a flow state. So if you can limit the volume of interruptions—noise from those working around them, phone calls (a five-minute phone call actually costs 20 minutes of flow time), or “urgent” e-mails—then employees can extend their flow time and subsequently deliver more output. Try to create a quieter work environment or encourage work conversations to be conducted in shared space (conference rooms, break rooms, hallways, etc.). Reward a culture that allows non-urgent information requests to be fulfilled between “states of flow” rather than real-time/immediate.
Additionally, limiting multi-tasking (Exhibit 4) can deliver improvements. A person with two tasks might result in a 20% loss of efficiency on each task. For example, if two tasks of 100 minutes each are worked together, the total time to complete both tasks would be more like 240 minutes. In isolation this may be tolerable, and admittedly, it is probably unrealistic to not expect some level of multi-tasking of most employees. But over the course of a day or week, and across a work force of say 20 people, those extra 40 minutes add up to real number. Try asking employees to work multiple tasks serially.
Exhibit 4 — ask Sequencing
Approach individual tasks with a single-minded focus. Let a phone call roll to voice mail, setting time between tasks to respond to messages that build up during the task. Leave the laptop at your desk when attending a meeting giving full attention to the meeting objective without trying to complete other work at the same time. Start the meeting on time. Turn your PDA to silent so e-mails that are arriving during a task do not provide a means for random interruptions.
David Allen has authored two books Getting Things Done: The Art of Stress-Free Productivity and Making It All Work that provide very helpful insight into solving this problem.
Create a physical work space that balances privacy and collaboration. Ensure that collaboration space (meeting rooms, public area white boards, conference tables) are easily accessible. If the individual's work space is not very private, normal in today's world of cubes and open office concepts, try to provide places where individuals can work privately.
Fourth, are roles clearly defined—project manager, architect, analyst, developer? Do multiple people attend meetings when only one is really necessary? For example, there is a meeting with the business sponsor to flesh out requirements for new systems. In many cases, we have seen both the project manager and architect attend the meeting, and in some cases that is appropriate. However, in many cases there is unnecessary overlap between the two roles. Allow one of the individuals to attend and give some latitude to that person to represent the interests of the non-attendee.
A second observation is that more information is gathered and distributed from the architect to the developers than is needed. Try to avoid defining specifications to such detail that the developer is being spoon fed. Rather, get enough information for the developer to get started and making headway, but allow the developer to fill in some of the gaps to keep things moving, with an occasional check-in to make sure the developer is on the right track. That streamlines the architect's efforts, and in most cases makes for a more enjoyable experience by the developer because they are getting to think along the way.
Fifth, once tasked with a project, are your teams allowed to complete their goal? Certainly, there is a time and place for changes in priorities. Try to avoid creating a culture of frequent changes in priority so that tasks can be completed. This not only helps to ensure work output is produced, but also allows the organization to build and sustain momentum that carries over to future objectives.
Plus, it avoids building a subconscious hesitancy to move ahead aggressively. If history shows that work streams will be interrupted on a frequent basis, teams will drag their feet when given new marching orders, moving more slowly than they would otherwise as they do not want to invest too much energy knowing It is only a matter of time before an interruption occurs.
Consultants are often bounded, and thus allowed to focus on a project or task, by an actual statement of work (SOW) that contractually defines the terms and output of a project. Companies can utilize a virtual SOW with an internal project team defining the terms, conditions, and assumptions associated with a piece of work.
Sixth, are people encouraged and even rewarded for surfacing issues and risks as early as possible? It is inevitable in most businesses that issues will arise, causing a team or individual to delay or side-track their efforts. The sooner issues are surfaced, the more quickly they get addressed and a team can get back on task. The longer issues go before being addressed, as in most procrastinations, the more difficult and time consuming the effort to put the issue behind them. Leaders should be asking for and expecting their team members to surface potential road blocks. When those ideas are surfaced, respond in a positive way and collaborate with the team or team members on their ideas to avoid or overcome the hurdle.
Seventh, does your team have the right talents to achieve the goals you aspire to? While each role in an organization needs the right amount of “skill,” it is generally more than just technical aptitude and experience that defines the success of the individual or organization in performing their job. Of equal importance is that the organization recruit and attract people that have the proper behavioral and emotional make up for the type of work that is being done. If your organization has frequent change or high-velocity demands, during the recruiting process you should interview for the types of behaviors and experiences that suggest a person can perform and adapt well in a structure with ongoing flux. Work toward having the right mixture of technical capabilities paired with business and relationship aptitude. Successful IT teams recognize their people need to be more than just a Java or .Net developer.
Eighth, are your processes aligned for velocity? For example, one of our clients has a production release schedule of every two weeks. This sounds good on paper—bugs get fixed and the overall business solution evolves fairly rapidly. Yet, a large amount of resources are consumed in the exercises necessary for a successful deployment with every release, which takes significant capacity away from on-going development activity. In this case the client might consider less frequent releases allowing for more time to be allocated between releases on “velocity-dependent” output and less time on velocity-killing efforts.
In summary, velocity is not a quality exclusive to consultants. Enterprises can and should expect to achieve similar levels of productivity that often appear to be the exclusive purview of consultant teams. As you look inward in an effort to improve the throughput of your organization, look for ways to address the following areas:
- Ensure IT team members are aligned with the vision and dreams of the enterprise, and that IT has the sponsorship of the organization
- Do things as a leadership team that allows people to move “all in” on a personal and professional level
- Create a setting where people can work privately or collaboratively as needed, reducing outside distractions
- Organize teams and roles clearly around an initiative, preferably keeping the team as small as possible
- Scope out the work and conditions as clearly as possible allowing the team to focus on a tactical goal
- Incent and reward the surfacing of risks and potential road blocks
- Leverage processes that fit the type of work being done or needed by the enterprise
- Hire appropriately balancing skill with behaviors, and attracting the type of people that can flourish in your environment.
Ballengee, B. (1996, 2003, 2007) Enterprise Architecture Framework, Dallas, TX: Bruce Ballengee and Pariveda Solutions, Inc. Permission granted to the SIM EA Working Group
Evans, M. (2009) Velocity is not just for Consultants PMI Global Conference, 2009 Orlando, FL, USA
McCue. (1978) IBM Systems Journal 17, 320–41
Patrick, F. (1999, October). Program Management – Turning Many Projects into Few Priorities with TOC. Presentation at PMI Symposium, Philadelphia, PA, USA
© Michael Evans
Originally published as a part of 2009 PMI Global Congress Proceedings – Orlando, Florida