Seven high level Business Requirement Drivers for Project Charters

Projects performed for most businesses have an expectation of providing a positive result known as a “Return on Investment” or ROI.  Businesses have customers, owners or stockholders whose interests are the driving purpose of the existence of the business.  It is very rare indeed that a project will be chartered and funded if the desired results are unknown.  The project could be funded, however, if the desired results are ambiguous and unclarified.  This could be likened to a stormy sea – it needs to be calmed by the steady hands of the project manager and the client sponsor, able to define the high-level business drivers.  These seven drivers are defined below.

Too often, the project is tasked to a team or people with a directive that does not clearly provide a vision for the intended outcome.  The project manager and the team become focused on the set of tasks, but the communication of the vision for project success is not adequately clarified.  The PM (Project manager) or team is told to “do” – to create a new feature, a new product, or a change to an existing product, without understanding the vision or purpose.  The project is expected to get done, when the “definition of done” or purpose, is poorly understood or defined by the people or person that is commissioning the work.

Project Managers (“PM’s”) are the point of contact for projects.  The project charter which should be created with input from the client stakeholder should expressly define the purpose and focus of the project in business terms, so that the completion outcomes are clear – that the “definition of done” is not ambiguous or uncertain.  The business requirements should then be crafted into technical requirements, which will become designs, and greater detail added as needed to drive the work of the project.  The question is:  what are the high-level drivers of business requirements?  How does a project manager focused on the “what” of actions and tasks – gain greater understanding of the “why?” – beyond the client simply saying, “do this.”

High level business drivers generally fall into seven broad categories.  These are the requirements categories into which the business requirements fall.  If a project manager is left with some question of uncertainty about the purpose (or “why”) of a project, these items will help to formulate questions to the client and obtain more and better understanding of purpose.  Below, I will provide a brief of the seven broad categories and examples for them.

Revenue:  Revenue is the gross income received in an exchange of value for a product or service.  In a financial sense, it is the term that is often defined by a period of time in days or by calendar increments.  It is also often associated to either of single product, a line of products, or a company’s overall income from sales or service provisioning within that duration.  Revenue is the life blood of nearly every organization without which they will eventually cease to exist; therefore, it is a major driver of business and a driving purpose for some projects.  It is also a factor in calculating the ROI of projects, because a project is an investment of resources, to gain a return.  Revenue has implications for profit and may be impacted or affected by the expense or cost of a project.  If a project is expected to increase revenue or “cash flow” it should define the change outcome: what the present revenue is and the projection or forecast of the increase in revenue from the current state – the delta or percentage between them and an understanding of how the values were derived.

Efficiency:  The reduction of waste or cost that may affect the operation of an organization.  This is an area where improvement is a focal point.  Companies can measure their existing (present) efficiency and from that can determine if a course can be charted to improve efficiency.  Efficiency improvement mitigates waste, uses fewer resources of money, time, people or raw material products.  Lean Six Sigma principles define tools and methods to assist with identifying possible sources of waste and inefficiency, which can then be targeted with projects to add action to a plan to achieve greater efficiency.  This high-level business purpose or requirement should be defined in a project charter so that the desired outcome is known.  What is the resource cost today in terms of money, people, raw materials, and time?  If the planned efficiency project is successful, what is the projected return for the estimated cost?  How is that efficiency improvement calculated – upon what baseline figures and who was responsible for assessment to approve the change project?

Productivity: The improvement of productivity is gained by process improvement and may be closely aligned with efficiency.  It is not merely the mitigation of waste or improvement of a process, but also focuses on systems and alignments to gain greater outputs, per the measure of inputs.  As an example, a productivity increase may be captured by new technology:  whereas an accountant must calculate business results for a businesses month end, this could be performed with a pencil.  Add a calculator and the accountant with be more productive.  Computerize the calculations with entered inputs and productivity rises even more.  Utilize better methods of capture on the financial data and even more productivity is gained.  All of this leads to how the time of the accountant may now be utilized for higher, more strategic goals and analytics instead of slogging through the calculations by hand, or with a calculator.

Image:  How is your company viewed by important non-company stakeholders?  Is it important that your customers, government regulators, stockholders, competitors, suppliers, etc. – view your company?  Image relates to customer service, product or service quality, reputation, and so on.  The perception of your company in terms of honesty and reliability all adds to – or detracts from – image.  Projects may be focused on “CX” or customer experience, so that the customer finds what the want from the company faster, purchases it easier, controls their account and relationship to the business more effectively, pays their bill sooner, and has more satisfaction with your company.  Clients sponsoring such a project should be able to quantify the present state and the expected future state of this project type, also.

Security:  Security could be physical or virtual, privacy concerns or confidentiality concerns, financial or intellectual property – and this list can continue.  Security may be the entire focus of the project, or it may be a part or portion of a larger project.  Having security or gaining security is an important part of a company reducing risk and mitigating loss.  Security influences nearly every other project aspect in relationship to IT projects as well as others project domains.  This business requirement driver must also be defined, quantified, and goals for results understood.

Stability:  Business drivers for stability include concepts like business continuity and availability of resources.  This may relate to inventory being ready when needed, or systems functioning at peak demand, or overcoming a disaster with a plan for service diversity and redundancy.  This requirement also may be a stand-alone project or a part of a larger program.  Company policy influences this type of requirement, but that reinforces the value of defining the expectation of outcomes.  Occasionally, this can become affected by budgetary constraints in negative ways which should also be defined and perhaps recognized for the risk factor.

Safety:  Projects to enhance safety are also often linked as a part of other initiatives.  This often implies physical safety, so would enhance the safety of workers, customers, traffic, inventory, property locations and so forth.   An example might be the acquisition and installation of an emergency phone system along the walking paths of a park or a campus.  It could be a guardrail.  In any event, an assessment of the current state and the expected state in terms of how safety is enhanced should be defined.  How many events or injuries have occurred to compromise safety in the past time period?  How would safety improvements reduce or mitigate the incidence of future events?

Summary

The high-level business drivers could possibly be remembered as a foundation for the storm which is project is to change.  The change that project engenders is to calm the storm, reduce the waste, the variable, the defects, the applicable business driver…  it is the pier, or PIERSSS that help anchor and support the high level business driver(s.)  Productivity, Image, Efficiency, Revenue, Safety, Stability, Security or PIERSSS is an acronym to assist in remembering for the project manager to ask the questions that can lead to better definition of the high-level business drivers, or to more effectively define the purposeful, expected outcomes of a project.

If this makes sense to you and you need a Project Manager or Program Manager to assist you with Planning responsibly, committing to a plan resolutely, and driving execution impeccably, please reach out to me at randall_tabor@msn.com, or 678-208-8828.

Advertisements

The role of requirements planning in a “WaterScrumFall” project environment – Understanding the challenge

Leaders know that strategic plans begin with a vision of the benefits.  Having a vision is paramount in driving a company to new levels of success, but when disconnected from the people who implement the plans the, “Understanding” is indistinct.  Sitting in numerous meetings, the phrase, “I (we) need to understand what is happening with…”  The pattern of “WaterScrumFall” is a management imperative to communicate what is to be developed, tested and delivered in relationship to Strategic plans, along with an effort to do the development work in an agile methodology.  Management wants to know what is being built and when, while the agile development team says, “We maximize the benefit of agile development when we refine the plan and code along the path of the product backlog.”  This means ongoing and perhaps significant discomfort for those people who must communicate release plans, progress on project scope, schedule assurance, meeting business models and processes, getting ROI, and planning for resources and integrations aside from the development effort.

The dichotomy (conflict) is that we must have enough transparency and vision clarity in the plan by way of requirements to ensure expectations are being met.  Before we take a trip, we determine a start and end point, and waypoints along the way.  On the other hand, we do not have to call the mayor to schedule all the lights to turn green as we approach each one.  To focus that thought: there must be sufficient effort and definition at the start of a project or program to have a firm foundation of requirements – a roadmap and purpose – for the expected outcome.  The product plan needs to describe the business “why” and cast a documented adequate vision of what is expected at a high level.

The effect to people

The agile team may resist crying that too much up-front planning “is not agile.”  Large companies, like AT&T, need that roadmap and the feedback obtained from it, and often end up using a hybrid approach of waterfall and agile.  This is sometimes known as “WaterScrumFall.”  Defining the launch/release criteria early in the process in a waterfall planning style, and then the development team runs the development as an agile approach.  Then, once the product is near release, they shoehorn the agile development work back into a waterfall schedule expecting that exactly what was expected at the front end is what will come out the back end of the project.  Management reviews what is being delivered and exclaims, “that doesn’t match what we agreed to!” and the development team is thinking, “that’s is agile development.”

The process can work, but it very often creates great strain on the organization.  Sometimes, development delivers something other than the original expectation and the risk is that it may be something better – or worse.  Development “develops” along the way in a feedback loop – which fits the adaptable nature of agile.  Two statements from the principles behind the “Agile Manifesto” fit in this context and can enlighten a path to mitigate the conflict:

  • Business People and Developers must work together daily throughout the project.
  • The best architectures, Requirements, and designs emerge from self-organizing teams.

Alignment or “Understanding”, as mentioned earlier, require both business requirements first, technical requirements second, and a product roadmap that is set into alignment in advance of a product backlog or release plan.  Requirements must include more than a statement of how something is expected to work, or even benefit the customer, but document the business purpose, the customers and stakeholders, the schedule expectations, priorities, and an overview of the systems and integrations that may be required.  While this is nowhere near a comprehensive list of requirement documentation attributes, it includes some topics that are frequently overlooked to the detriment of the project or program, stakeholders, and customers.  Both management and the agile teams need to define ways to respect the divergent philosophies and seek the best attributes and advantages of each to maximize value to the stakeholders and stockholders.

Head down working may also means broken focus

The plan initiation and initial activity shows promise, but things seem to slow down, the backlog increases, new scope items arise, defects stack up, frustration rears its ugliness.  Leadership – who have approved the vision and requirements – must clarify the vision.  Business people must be intimately involved in directly collaborating to foster focus on the highest values, keeping “The main thing, the main thing.”  Obtain real customer input on what is best by listening.  Redirect the teams to business use cases to ensure the developing product has the attributes defined by the requirements.  Ensure the developers, and contractors are not enduring obstacles preventing delivery of the highest value fitting the purpose of the program.

Refinement

An element of waterfall planning is a lack of adaptability or agility.  We know change is inevitable, but usually the strategic vision is fairly static.  Requirements classify and define in ways that can lead to later obstacles, dead-ends, or process-driven “Change Requirement Board” reviews.  Agile deals with this inherent in the process, but traditional Waterfall does not easily accommodate change.  In any event, the refinement of requirements also requires ongoing collaboration between customers, stakeholders and development to refocus the vision when challenges are identified.

In requirements gathering, the most important question is why.  When, who, what and other questions will always take a backseat to why because it drives project purpose top to bottom and start to finish.  Why (purpose) assists to define risks, benefits, and priorities.  It also informs every other aspect of the program or project.  I would be grateful to have a chance to work with you in a leadership role for Project and Requirements management.  Let me know if we can discuss it further.

 

Diagnosing hidden issues in Complex Change

Primarily in a business setting, strategic change is potentially disruptive.  Changes of a strategic nature involve more than just a minor new thing.  Obstacles to change are sometimes obvious issues:  lack of raw materials, products unavailable on time, dependencies incomplete.  Project and Program or operations managers may be challenged by these issues, but they are identified and a plan to contend with the issues can be defined and implemented.  Not all change issues are obvious.

Large scale and disruptive change must be managed differently.  As a leader of significant change, there is not always an easy path to success because it is all new.  Project Managers and Program Managers are often engaged in a project or program while it is progress.  In these cases, they may be replacing someone or being positioned to solve a problem with Schedule timeliness and delays, scope creep, budget overruns, scope quality mistakes or other costly issues.  When the issue causes are hidden – not the obvious issues – it can be challenging to diagnose the root of the problem.  These hidden issues are first recognized by how the project or program “feels.”  The old phrase “two steps forward and one step back” comes to mind.  Suspicion that “something is not right” creeps in to thoughts.  Experienced Project Managers are now nodding their heads, knowing they have experienced these feelings of uncertainty and doubt.  The problem is made even more difficult if it takes a while to figure it out: in the heat of managing the plan, the problems persist and continue to interfere in the background despite the effort expended to move forward.  The issue is more difficult to diagnose, because it is not readily identified or defined.  Like a car that has one bad spark plug, the project moves forward with one unidentified cylinder knocking and sputtering.  Which spark plug should be replaced?  Must all of them be scrapped and replaced?  Likely nothing must be replaced in a project, but instead, one must consider objectively the “feelings” of the project team, and from that intuit the root of the issue.  Once that root is determined and no longer hidden, it is like any other known issue – a resolution plan is implemented and the issue is mitigated.

Missed start dates or delays in getting things done on time could be due to lack of a clear plan of action, failure to communicate it adequately, or a poorly communicated vision.  Missing the necessary attention from the person who has the expertise to take the next steps (like a missing technical design) may be a failure to understand the benefit or value in doing the work, or a misunderstanding of the vision or purpose, or disagreement of the priority of the action.  In any event, it requires some thought to determine what the missing element is in the leadership of the project or program.  The table below offers some insights into how the “feeling” may be used to diagnose the root cause of the problem.  It is always best to view the issue as an unintentional consequence of the root cause rather than an intentional problem with the human resources.  When the root cause is faxed and the blocking obstacle is removed from the team, expected and reasonable progress may resume.

Are there other feelings that expand upon the chart below?  Other unique hidden root causes that relate back that are not found in the table below?

complex media3.png
Skills
:  expertise, experience or specialized knowledge that may contribute to a projected outcome.  If the project lacks this, it may occasionally be hidden in the complexity.  Review the stakeholders and inquire about skills in relationship to the scope and quality demands to reveal any lack.

Vision: a compelling future state.  Communicating this vision in a way that compels people to action is often a way that persuasion begins.  When the vision belongs to “someone else” it may require regular repetition to retain awareness of purpose by others.  A project “kickoff” meeting should be the initial communication of the vision; however, with large complex projects arises an ongoing change in active resources (people) who may not be aware or remain aware of the compelling future state.  They may have other high priority activities that interfere.  Regular repetition of the vision will repair the broken focus that sometimes infects projects.

Benefit: the end state to the vision.  Incentive:  the reward or achievement obtained when the outcomes match the expected scope end state.

Resources: raw materials, time, budgets, space, or other gaps aside from knowledge skills that may arise without prior awareness.

Action Plan:  A breakdown of the required project or program work sufficiently adequate as to leave no doubt about the next step action items.

Top Line Project Prioritization

Prioritizing – a concept that guides and informs our decisions for many aspects of our business, our daily schedule, and our lives. In terms of our lives, we may have many things at the top of the list – faith, family, friends, vocation – and how these concerns intermingle and are cross connected. When the time arises to determine what takes precedence, the decisions are still difficult and confusing.

In business terms, we may only be able to provide the most focus on the highest priority concern. Many people would agree that the highest priority for the accounting department is to ensure that employees are paid on time and in the correct amount – as an example. In terms of managing projects the controls of what takes precedence or priority over another concern should be clear and planned in advance. The definition of priority informs the project manager and the team of the order of precedence for decisions and tasks so that the ordering of them in terms of importance can be determined. The bounds of this prioritization may be to satisfy company goals or an important contractual agreement. Missing, skipping, or simply failing to order things according to the priority – even if it must later be changed – can result in significant stress to many or all stakeholders. This is especially true for the Project Management stakeholders.

Project Managers should guide both the understanding and the formulation of prioritization, but should not be the person accountable for the decisions in their entirety. Clients, product owners, IT/S leaders, company officers, and even key users and support people should have some level of input into elements of prioritization.

In terms of the overall project constraints, Project Managers may have their professional reputation concerns in mind when determinations are made about the most important aspects of the project. Now we are focusing in on the highest general concerns of the project – the “triple constraints.” Budget, Schedule and Scope (within Scope and for the sake of this discussion I include quality.) Every activity of the project could impact these three constraints or the constraints could impact the activities or outcomes. As Project Managers, we should remain cognizant of these items as a matter of professional purpose. The concern is heightened somewhat when we have a stakeholder who suggests that these three general constraints all have the same level of priority. This makes the Project Manager left in the dilemma of “Superman,” being forced to decide whether to save Los Angeles from the earthquake or New York from the Nuclear holocaust.

Projects are instituted to manage change; therefore, change is an expected aspect of a project that must be monitored and controlled. Any change that occurs must be documented and accounted for in some fashion. This is true of Traditional or Agile projects (though agile has more adaptable methods of working through change.)   When we recognize that change is the exact reason for the project, then additional change should not be too surprising. The problem that requires resolution then leads the discussion back to prioritization, and expectations for performance in terms of the triple constraints. Setting these expectations early and using the expectations in future resolution determinations can assist in faster judgment by stakeholders and less stress for the Project Manager. Our guidance can be based on what is already a known factor for the project.

When your executive stakeholders relate that Budget, Scope and Schedule are all three of the highest priority then they fail to understand the definition of the term Prioritization. When faced with a critical concern that requires an unpleasant choice about one of these three general constraints, it is often too late to seek objective evaluation of the most important value – the highest priority – for the project. While we can use the (Non-) strategy of hope – as in we hope we will not be faced with this situation – Mr. Murphy (of “Murphy’s law” fame) will invariably show up to remind us too late that this decision to leave stakeholders unaware and in the dark was not a workable choice. Gaining agreement in the early stages of the project to determine which of the three – Schedule, Budget, or Scope – is the highest priority concern will mitigate the negative consequences to the Project Manager.

Remaining mindful of the fact that the triple constraints are the “raison d’etre” (French for – the “essential purpose”) of a project manager, level setting with client stakeholders to examine and determine, in advance, the highest priority does not relieve a Project Manager of attaining project results. However, in recognition of the nature of change, a Project Manager does not have an accurate crystal ball and cannot be prescient in terms of every potential change – within the change – for a project. When a change occurs that threatens to change the course of project progress, it will be useful to know in advance what priorities are placed on the general project constraints. The image below may of help in making worthwhile determinations.

Priority tradeoff Matrix 2-13-2015

Using the image above, a Project Manager may engage client stakeholders in discussions guiding them to more specific conclusions about the order of priority for Scope, Budget, and Schedule. This could potentially open up discussions about each concern, but this would serve to further define highest priority, and may also reveal project risks that have not previously been revealed.

Fixed priority items are those that the stakeholder has determined cannot be changed or the risk to the project results is too high against expected results. Firm priority denotes items that may risk loss to company expected results if it occurs, but would be less damaging than the fixed item. Flexible, as it suggests, is the area where control and change may be less damaging or more acceptable if change demands arise.

Not every project risks company assets, results, or image; but, Project Managers are engaged for risk management and communications skills. Using this information above helps to control and mitigate concerns with fundamental and defining project attributes. The use helps foster consultative communication, proactively guiding client stakeholders to provide clarity and focus on the highest priorities for the project and providing clear notice to the Project Manager of the most important constraints for the project.

Business and IT – communication delta

At times it seems like a chicken and egg moment – the question of which came first?  From the business perspective, IT seems to have gained a position of being an end unto itself – technology for technologies sake.  A showcase of how a company has found technology, and people to operate it, that sets it apart from competitors simply because it exists, is unique, and the features are now in the range of science “non-fiction.”  The “yes we can” moment that has some business pragmatists wondering, “sure we can, but why?”  IT executives find themselves trying to position new technological solutions to business people with the trite commentary that this new feature is “a ‘no-brainer’ because of the technical advances.  Conflict abounds, because both parties may be “talking past” one another.

Business leaders are becoming more tech savvy both in understanding the technology and the business value it may enhance.  Business leaders are performing more research and finding efficient ways of meeting goals with concern for cost and more focus on simplicity, basic functionality, and cost efficiency.  That may work, but not always because it may not scale, likely does not provide customization for a specific need, is not necessarily secure, and does not necessarily meet legal requirements.

In the end, the business people seek to fulfill business needs and expect IT to be an enabler of better results.  There are several broad areas where businesses always seek results:  Increasing revenue, reducing expenses, improving productivity, enhancing image (such as customer satisfaction scores), stabilizing risks and issues, lessening security volatility, keeping employees and customers safe.  IT can have a positive impact on all of these concerns – as long as they have been provided a relevant focus by the business.

A major focal point is ensuring that the business and IT have a common interest in an desired outcome or goal.  Frequently, it helps to have a person facilitating and moderating the discussion and planning between the two groups to ensure accurate and productive communications, translating the language of business into project feature elements for IT, and documenting the ideas and decisions for the proposed actions and project.  This is assistive in mitigating gaps in the determination of requirements for meeting the project purposes.

In both cases, it involves change for all.  Why change? Because the things that bring you to the present, may not carry you into the future.   Change is disruptive and engenders risk, but both can be controlled.  One question becomes – can you fulfill your current role and also manage the disruptive change and manage the attendant risks and issues that are likely to occur?   W. Edwards Deming identified a beneficial cycle for improvement: “Plan, do, act, check.”  One can further add the concepts of inspect and adapt.  Are you adept at these ideas, experienced, ready to add these broad activity areas to your new management initiatives – and have the time?

A vision for valuable change is completely without value unless it is implemented.  With the understanding that a plan must be evaluated, once the value proposition is deemed worthy, it is now just a liability unless it is put into motion. (“Shoulda, coulda, woulda”)  This is the reason why there is growing momentum behind IT becoming a broker of services or a consultant enabling new business initiatives.  IT is now leading not IT changes as such, but assisting with setting business strategy and acting as the enabler mentioned above.  The handwriting is on the wall according to a CA white-paper, “The changing role of IT and what to do about it.” (2014) providing the statistic that 35% of new IT technology spending is now being spent outside of the IT department.  This is clearly defined as requiring business leaders to manage vendor resources not just direct employees.  Get the white paper now

Projects providing transformative and new plans require new expertise not necessarily available in the existing IT department.  New software, new hardware, new infrastructure and network, and new thinking or training.  Professional Project Managers are trained and experienced to manage change and risk with responsible levels of artifacts and documentation for communication.  Projects are unique in some manner and have a specific duration – a lifecycle with a beginning and an end.  This requires a big load of “soft skills” like effective communications, but includes hard skills such as listed below.

  • Projects must be integrated into current company processes and fit with the company purposes.  Changes that arise affecting the project plan require an accounting of the impact of the change and a system of approval to address the change as a part of the existing plan.
  • Projects have an either narrowly focused or broadly focused scope of application depending on the level of definition available at that moment.
  • Projects have a schedule that assist in the determination of the beginning and end mentioned above.  This may be very detailed or roughly estimated depending on the depth of planning at the point of the inquiry.
  • Project costs are considered, budgets formulated and funding requirements at an acceptance level to allow next steps, if not completely contracted.
  • Project quality, acceptance standards for completeness, and steps to evaluate or test results have been planned and documented. This reduces stakeholder confusion about what is included or not in terms of completeness and function.
  • Human resource needs are identified and plans to commit the people to their specific area of responsibility is planned with authority to execute the project.
  • A communications plan is prepared to meet the requirements for managing the information responsibly needed for project performance, including periodic information on aspects of the project determined by company process or stakeholder needs, (an example of this may take the form of a weekly status report.)
  • Risks must be assessed and issues or concerns that arise from unexpected consequences of change, impediments or lack of resources must be addressed and managed.
  • The need to acquire materials or resources (procurement) must be planned, conducted, administered, and contracts satisfied and closed to meet legal and ethical requirements.

Project managers that are Certified with the Project Management Institute “PMP” (Project Management Professional) certification have met a high standard in terms of proficiency managing projects.  PMP’s that have experience in the IT domain may also act as that communication facilitator between Business and IT.

The strategic importance of IT continues to increase.  Cost effectiveness requires increasingly diverse resources and more widely focused products, applications and features.  The road to reach the next goal is bumpy but can be made less so with a project manager.  Reach out and I can help you determine how this may work for you.

 

Landline Voice versus Wireless mobility voice – sound quality. Winds of change…

It has been always recognized that the quality of telephone voice communications has been best over traditional wired or landline telephone versus over mobile or cellular phones. Read on, this is poised to change.

For those who do not know, cellular telephones currently use a narrow band technology for voice. Despite the proliferation of “LTE”, voice communications as of 16 May 2014 remain on the traditional cellular networks that link each voice call through the publicly Switched Telephone Network in the same way your landline phone is connected – over “circuit-switched” lines. Circuit switched lines have a limited, or narrow-band, of frequency of sound that has been in use for decades. When the challenges of the radio access network are added in to facilitate a voice call, the sound quality challenges increase.

Except in research and testing, voice calling has not been performed using the LTE cellular network. “LTE” or “Long Term Evolution” is cellular data access for your web browsing email and in some cases, texting. Cellular carriers have intended to eventually migrate voice calls to the LTE sub network from the beginning, but the technology was still developing for purposes of voice communications.

Forecast for Friday, 23 May 2014

The Windy City will be able to experience the winds of change. AT&T, “Mobilizing Your World” TM, is launching Voice over Long Term Evolution or “VoLTE” in the Midwest to include cities like Chicago and Milwaukee. This is only the beginning of a long and massive roll-out in five regions. The question may now be, “So what? What do I get out of it?” The answer is High-Definition Voice or HD Voice. HD voice will be included free with AT&T service to all cellular subscribers who must: have a VoLTE capable handset, be in a region where VoLTE service is enabled, and connected to another VoLTE ready subscriber. In order for wide-band “HD” voice to bring full value, it must be shared with someone using the same levels of technology. The reality is this will not make a difference for people not prepared to upgrade handsets this fall and will not apply to people that are not in the VoLTE coverage area; however, it is important for the future of mobile communications and is a historically notable accomplishment for AT&T, again.

The migration to VoLTE is a major refresh of the Cellular system that is more significant than “3G”, “4G” or LTE alone. It signals the evolution represented by “LTE” is going to make a difference for mobile voice communications for the first time since the early 1990’s. It will mitigate the requests to your caller to repeat themselves due to bad links, muddled sounds, background noise and conference call participants being told to “mute yourself.”  When you have a chance to hear the improvement (because one VoLTE subscriber connected to another VoLTE caller) you will recognize that the difference is dramatic.

I am not a shill for AT&T despite the fact that I am a subscriber and have worked for them. The advantage of this new technology is simply and frankly significant. That significance will not be realized by some users for months or even years perhaps, but it is significant nonetheless.  I am excited for the technological future this represents and hope to someday (sooner rather than later) have use of VoLTE technology.

Leadership Over Methodology

Leadership over methodology

Much discussion, to the point of debate, has occurred regarding the concept that a traditional project methodology or an agile form of project methodology is a better approach. This debate has been ongoing for some time with too little consideration given to the project attributes that may find advantage in one method versus the other. Evaluation of statistics direct attention to failure rates as an example to make a point about how superior one method is over the other with regard to the triple constraints of scope, schedule, or cost.   While this discussion rages, strong project leaders are delivering successful project results in spite of whatever methods or processes are employed.

Points about methods

Once all of the emotion or preference is set aside on the topic of methodology, realization that each offers benefits to project results is recognized. Each methodology has benefits to the projects where the methodology best fits. One quote puts it this way: “If uncertainty is high and the requirements are fluid, it is common sense to use an iterative method. If the deliverable is critical and it’s execution and use involve life and death you may want a strict development methodology.” (Dr. James T. Brown, PhD, PE, PMP; 2010)

While the comparative of fluidity versus life and death appears to be two ends of a wide spectrum, it may make sense this way: A road through a wood may follow various paths to traverse that forest. Installing it could be performed using an iterative method, finding the best path among the trees to reach the other side. When the road is 80% complete, a traveler could traverse the road with results limited to 80% before the traveler would be forced to stop or turn around, unable to complete the journey with full success. Now imagine that within that forest there is a river gorge that must be crossed. The traveler may refuse to begin to cross the bridge over that river once told that his chances of reaching the other side were 80%. In this case, the bridge may require certain and well defined requirements that may be best followed using well tested and strictly followed scope qualities, budget and perhaps schedule specifications.

Additionally, where feedback and experience with results affect outcome with improvements or enhancements, an iterative method may be useful. The bridge example above might include adding enhanced guard rails or smoother expansion joints once a safe installation has been completed. One of the best examples of an iterative product is one where there have been an initial, important result accomplished, and then enhancements offering greater benefits are later added. Releasing a product that is correct up to a point would be useful, if users of the product are aware of the need for feedback, improvement, and fixes to details that may not be working as preferred. An example might be a dishwasher that washes dishes adequately, but drying needs improvement and additional cycles to enhance the wash process could be added with user feedback.

Where the leadership impact is greater than the method or process

Choice regarding which methodology will best suit a project can best be made by an experienced, strong leader. Too much process and methodology can contribute to project failure and balance is needed in decisions surrounding project approach method. Flexibility and the agility to make needed changes remain apparent in projects whether the methodology is traditional or agile. Trade-offs are sometimes needed and good leadership can identify the reasonableness or risks of the trade-offs in relationship to the valued results. Exceptions to process or even methodology and scope violations need to be identified and have formal approval provided. Without a formal approval process, project integrity is eroded and results are questioned or lack credibility. Requests for change with strong leadership will assist in finding a proper balance point between targeting good results and having process for its own sake. Keep in mind that project management is ultimately just a formalized structure for organized common sense. Strong project leaders put the “sense” in common sense.

Preferences for a leader – talent or team collaborator?

At a recent meeting of 300 Portfolio, program, and project leaders a poll was taken to examine preferences for specific leadership qualities. While the best leader would have excellent team work and excellent talent in the same individual, if you could only choose one of the two attributes, what would be your preference: excellent team-work with marginal talent, or excellent talent with marginal team-work?

A live vote was taken and the results were very one-sided. 90% of those polled chose excellent team-work and marginal talent over excellent talent with marginal team-work skills. One of the questions that could be asked when these results are revealed is why? The answer may still reside with leadership. A leader with team-work skills will be better able to capitalize on the talent and skills of the overall team and in the course of the project come out ahead utilizing the skills of the whole team. A leader with talent and marginal team-work skills may only have her or himself to rely on, failing to have the advantage of the whole project team to realize best results.

A project leader will be instrumental in overcoming challenges to successful project delivery. Deciding with the team on an intelligent (and some might say wise) path of resolution, being confident and resolute in committing to a solution, and executing well on that solution with confidence sets a positive tone for the team. Being uncommitted, doubtful or unsure, or expecting that someone else will make all of the determinations will lead to paralysis by analysis.

Hard skills versus soft skills

A high profile example of how hard skills and soft skills affect team performance can be observed in sport team coaching. Coaches are usually recognized as being good leaders, but not always as having the skills of physical ability or skilled performance as team members. The coach’s contribution to strong team performance is undisputed, but the ability to do the work of any particular team-member is very questionable.

Lists of factors of leadership may include physical ability, performance, individual knowledge, persona, attitude, integrity, enthusiasm, encouragement, and consistency. Among these, factors that are most controllable are persona, attitude, and integrity. Individual knowledge relies on current updates which may be somewhat transient, especially when scope standards and requirements can change (particularly from one project to the next.) Physical ability may degrade over time or with injury. Performance of an individual may vary more than team performance. By building a team with the needed skills, a project manager can lead that team to greater results than what will be achieved by an individual or a loose association of people acting individually.

In the same meeting mentioned above, another survey was performed asking about choices for team leadership. The 300 people were asked to reflect on a sports team leader to choose persona, attitude and integrity; or, physical ability and personal performance in reaching high team performance. 94% of the 300 people chose persona, attitude, and integrity over physical ability and personal performance. The fact that these chosen attributes are controllable can empower teams to higher performance. A team leader can learn new knowledge needed to lead a project and can gain in individual performance, but the controllable attributes must be in evidence before the leader can be truly considered a leader.

In sports, a lot of winners believe that “home field advantage” contributes to winning percentages. It has little to do with the specific location or type of playing surface, but instead can be broken into factors of enthusiasm, familiarity, encouragement and consistency. When a project leader fosters an atmosphere that includes these factors, even greater success can be gained. These factors can also be controlled by a project leader. A project leader can learn to act enthusiastically, seek and provide familiar relationships within the team, encourage team members in the direction of success, and the team will benefit from consistent behavior and treatment. This subject area alone could foster a long paper and there have been books written about them. It is mentioned here, because it offers more insight into a leader’s ability triumphing over mere methodology and process.

Managers lead for success – Leadership over methodology

One of the most important efforts a project manager can make to help ensure project success is to anticipate aspects of the project. Anticipation is forward looking and proactive, versus managing the existing project conditions. Anticipation may focus on resources, risks, scope variations, budget, schedule challenges, and so on. Anticipation largely relies on communication and collaboration between the project manager and the key stakeholders, including probing for potentialities for the project. The question beginning with “what if” may come to mind in relation to seeking to anticipate. Much research is available identifying where project problems originate. The variables and factors likely to cause project problems reveal most of these are concerned with: defining project purposes, scope, or product attributes, poor planning, or lack of communication. All of these concerns can be substantially mitigated by having a strong leader managing the project, not simply managing by methods or procedures. Leadership attributes, engaged in a project management role, and exercising worthwhile methods and processes, enhances greater project success.