Do we fully understand Scope Management?

The record of how information technology projects fail has been studied and documented in numerous reports, such as the CHAOS, McKinsey, etc. The staggering statistics of the percentage of projects failing to meet their schedules, experiencing budget overruns, and failing to deliver the promised business value doesn’t always lead to technology as a failing component. The origins of failure often are not associated with technology but the people unable to relate to the scope in the big picture and the inadequate controls in the processes. In this blog article, let us focus on requirements on some of the less known aspects of scope – the boundary of what controls what the project should deliver!

Scope Grope: One of the less familiar aspects of scope management that plague the software industry is the team’s inability to articulate the requirements. These requirements manifest themselves as the rough draft of “wish lists.” This may also include some of those “gold-plated” features that are thought to be adding value. However, since these requirements are not solidly grounded in the technical, operational, and economic feasibility, these requirements do not strategically relate to winning more business, streamlining multiple channels of engagement, increasing employee performance, etc. These kinds of requirements become the "scope drifters" and are often a "productivity spoiler" and "promises stealer" because the business team fails to articulate the requirements clearly for subsequent analysis and design.

Occasionally, this challenge may further be passed from the business team to the technology team where the requirements further need to be assessed for technical plausibility within the constraints of human capital knowledge, budget limitations, security and compliance considerations being some of them. This scope grope may further be experienced by delay tactics by execution team members and the agile approaches to time-boxed delivery may easily be used to consider spikes as a limited experiment.

Among the many techniques available to use, a good technique to consider by both product managers, project managers, and business analysts is the SIPOC model. Using this model can help understand the relevance and importance of the entire value chain and the business impact of delivering or not delivering these wish-list features! Additional techniques include the benefits register, use case diagram, SWOT, PESTLE analysis, etc.

Scope Creep: This is a popular terminology even among agile practitioners that despises anything plan-driven. Although many relate to these concepts, there is a misconception that scope creep only involves the addition of new features not originally in the scope. Scope creep may also result from removal from scope any requirement and based on the time of the request, there may be rework required to revert some or all the changes done.

Perhaps mistakenly inherited from some of the account managers viewing scope creep as change orders executed with their client to reconcile financial changes in scope, the need to understand the process used in managing the product, program, or project cannot be emphasized more. Any organizational change control policy or governance framework must document changes not in the form of scope initiated by the client or product managers due to the market forces in the form of new or modified requirements but also the changes to the environmental context that also impacts the project’s schedule, cost, risk and quality.

Since the scope may have to reworked to bring the project to the same stability before additional work can be executed or released to the customer, the project manager’s astute awareness of the commercial and non-commercial aspects of the project’s boundary conditions may very well require additional stakeholders to be identified.

Scope Kill: It is an attempt to disengage with new ideas because the project’s operating framework doesn’t allow it, or the organizational culture doesn’t have an appetite for innovative ideas. There are many reasons for these "scope kill" contributors and some may include the scrum master not parking new ideas to be discussed at a later point and using time-boxing as an excuse to immediately mute the flow of ideas.

Several tools exist to control scope but one of the most critical tools is to have a RACI through which the Stakeholder map can be formed better to build alliances and form bridges to ensure that benefits are aligned, risks are mitigated, and quality is not compromised. The other tools include risk register, communication plan, stakeholder register, risk-adjusted backlog, a documented change control process and blue ocean thinking.

Scope Leap: Another uncommon terminology related to scope management is the scope leap, which is a result of a dramatic shift in the strategic focus or tactical direction of the organization altering the backdrop under which the project, product, or program is operating. In such cases, the measurable organizational value (MOV) no longer holds true completely. As a result, the focus of the minimum viable product may also have its significance for the product and project managers.

The biggest challenge comes when the same techniques for handling the Scope creep are used. Often, scope leap is happening when the project is in-flight, and it is understandable why one would resort to these techniques. However, since the project’s assumptions and subsequently the charter have been changed, getting back to the scope grope tools is better to revalidate ourselves before moving forward.

In the end, before any technology can be associated with a project’s failure, think of the role played by people, process, and organizations on a product and project’s scope and the resulting outcomes. It is possible for an IT project to fail because of technology but not all the technology project's failure come from technology failure! 

Product Management versus Project Management

As I was concluding a capstone class on project management, there was a question from a few students on whether there is any scope of career growth for project management as a profession with the increased focus on agile principles. Questioning further, the root cause of this concern was the fact that agile approaches, such as Scrum, do not call for a project manager role and the focus is only on product management. In a brief attempt to address these ongoing confusions thinking product and project management are mutually exclusive disciplines with product management slaying the project management field, I explain here the ongoing need for the symbiotic relationship between these two disciplines.

The experts in the field agree that a project is a temporary endeavor to create a unique product, service, or result. Inherent in this definition lies an inexorable relationship between these two disciplines. The project management is a set of processes, tools, and techniques that is indispensable to bring a product into the market. Therefore, a product cannot be delivered without the strategic focus on execution that only the discipline of the project management can provide through the phases of initiation, planning, execution, control and closure.

Does that mean product management is a subset of project management? Definitely not! I say this with so much certainty because project management is temporary in nature unlike product management that has a longer time horizon. Consider bringing to market a new hybrid car that runs purely on water! The product management may focus on generating the ideas, evaluating the alternatives, assessing the feasibility, and creating a business case at the beginning. Hence, the product management will have to think of a strategic road map of scouting the external and internal environments by applying the Porter's 5-force model. This 5-force model involves the availability of substitute products, bargaining power of the buyers (price consciousness of buyers), bargaining power of suppliers, those that supply goods), rivalry among the established firms, and the threat of new entrants.

Finally, after all the commercial, technical, and operational considerations have been addressed, the business case from product management becomes the starting point for project management to intervene initiating the project charter putting together the scope statement followed by the work breakdown structure and the sequence of activities that need to happen for bringing the hybrid car to the market. Now, if project managers only become tactical, then, they lose the ability to question the inherent assumptions to avoid a strategic failure. This fundamental need is why the businesses label the areas they need to work on as "capital project selection." The "capital" adjective here is a strategic decision making to ensure that the investment of funds, time, and resources are used to maximize the organizational value.

It is therefore evident that the product management defines what and where we should be doing while the project management tells us when and how we could be getting there. But the project management is like the Phoenix bird that ceases to exist as soon as that need of product management through the project management has been served. However, as the product management continues its journey through its lifecycle of development, growth, maturity, and retirement, there will be additional needs that will come up and the Phoenix bird revives itself again. Therefore, the good product managers will know that they need strategic project managers as brainstorming partners and similarly the good project managers will have more strategic thinking beyond the organizational context to support the product managers. Each profession, as a result, has a symbiotic relationship.

What do you think? Please respond with your comments.

Lessons learned: What the Silver Screen Cinemas can tell us?

I have been an ardent advocator of teaching the basics of project management, leadership, and emotional intelligence throughout my training and teaching career. In one of the recent classes that I was fortunate to facilitate, I used the example of Apollo 13 motion picture (Grazer & Howard, 1995) to illustrate to the class about the practical realities of how risks and quality can severely turn the happy path scenarios around. It was a revelation for the class as the various teams related to the emphasis of the "unknown unknown" risks on the management reserves, the criticality of risk identification and management strategies on contingency planning, influence of leadership on the conflict resolution and negotiation, etc. Synthesized in this blog are the major lessons that evolved from the class. When used effectively, the use of movies can become an effective tool at both academic and practitioner settings.

One of the first lessons was the importance of the timely response to strategic changes in direction as management and leadership reestablished the priority. Not only did the NASA management disregard the original mission to land on the moon but quickly established the revised project goal as they reset the impossible expectations on the on-ground team to bring the astronauts back to earth! Even at a tactical level, when one of the engineers pointed out how much power they need to conserve to return to earth, the decision-making was quick. One may question the time taken here because all these discussions were captured in a movie. However, when relating to the Apollo 13 timeline (n.d.) that were documented by where the entire episode of the discovery of the problem to the egress of the astronauts from the command module was approximately only 2.5 days, the importance of decision making cannot be overlooked.

The recurring theme among the teams was the relationship of proactive risk management. A space shuttle launch initiative is a major undertaking and risk management is a sine qua non of such larger programs. Yet, when the calamity dawned on the team, it became apparent in the class discussions how many of the risk response strategies had to be reworked identifying the secondary risks of the release of unsafe chemical gases and attempts to squeeze more power from modules for which no clearly documented procedures existed.

Another theme resonated nicely from the discussions was the importance of stakeholder and communication management. As heard in the movie, “Failure was not an option,” for NASA but there were several stakeholders in the power-influence grid that needed to be managed. The team’s efforts in managing these numerous stakeholders’ expectations during this major recovery exercise were commendable particularly when the only available communication channels available at that time were the radio, the television, and the newspapers. Managing expectations of public relations was still achieved in the absence of today’s Internet-connected social media world.

An interesting point was the class focus rested predominantly on the on-ground team efforts until discussions were brought on the astronauts that needed to execute these sequences under entirely different situations of limited heat, extreme stress, limited resources, and intense focus. These facilitated discussions further highlighted the analogy to the gaps experienced with the distributed, virtual, and remote teams were brought to light.

In summarizing, this exercise brought a good closure in bringing home the vital elements of management and leadership while constantly managing the emotions expeditiously and relating to the basic principles of project management.

What other movies do you think can bring home similar experiences in a teaching or training setting?

References

Apollo 13 Timeline (n.d.). Retrieved November 30, 2016, from http://history.nasa.gov/SP-4029/Apollo_13h_Timeline.htm

Grazer, B. (Producer), & Howard, R. (Director). (1995). Apollo 13 [Motion picture]. United States: Universal Pictures.

Management Debt: Costs of Non-delivery and Non-conformance

The principles of lean have always focused on maximizing the value delivery. In fact, the Japanese term Muda (Arnheiter & Maleyeff, 2005) refers to the seven different types of wastes that one should remove. Expanding on this, practitioners have added the non-utilization of talents introducing the mnemonic or memory aid, DOWNTIME, to capture these eight types of waste an organization or project should closely monitor to increase efficiency. These eight types of wastes are:

1. Defects
2. Over-production
3. Waiting
4. Non-utilized Resources
5. Transportation
6. Inventory
7. Motion
8. Excess Processing

It should be noted that the non-utilization of resources was not part of the original Lean Manufacturing concepts that were formulated based on Toyota Production Systems value chain thinking (Sutherland and Bennett, 2007). However, as the ways of working emerged shifting the focus towards value creation applicable from all levels of the organizational hierarchy such as the open systems thinking (Scott, 1981), non-utilization of resources was added as the eight types of waste! In my opinion, this is applicable in any industry as resources can be both human resources (people's time, skills, talent, experience, competency, etc.) but also non-human resources (facilities, equipment, materials, infrastructure, supplies, etc.)

Often, these eight principles are considered an academic exercise and practitioners have lost connection with these principles. Unless these principles are related in terms of the management language, money, these principles don’t gain the limelight. In this blog article, I would like to synthesize some of these principles in terms of two types of costs as follows that relate to the cost of poor quality. When these two costs are not managed appropriately, it is management debt to the project.

Cost of non-delivery

This principle refers to the “…measure of the costs associated with preventing, testing for, or correcting defective items,” according to Carr (1992, p. 72). The cost of poor quality comes from both the internal and external failure costs where poor-quality costs are associated with rework, redesign, retesting, failure in or shortage of specifications in requirements, bugs arising from poor development practices or myopic understanding of or inaccuracies in requirements or design, or unplanned delays in monitoring the dependencies. All these relate to elements mentioned in the DOWNTIME factors and could lead delivered work that is still not production ready unacceptable for customers. Say, if any of the above factors contributed to a schedule slip of 10% on a project that cost $100,000. At a minimum level, this slip means $10,000 (10% of $100,000) is now an additional cost to the project that could have been effectively controlled.

Cost of non-conformance

Non-conformance means the rules of engagement for a specific development or management methodology are not completely adhered to. For example, not following the integrated change control mechanism to use a tool that is not approved by the organizational policies, not adequately preparing for the specific meetings increasing the cost of a meeting, taking missteps that lead to the escaped defects increasing customer’s bad will, or over-engineering a feature beyond the fitness for use. When these things happen, it often involves more time spent in corrective actions introducing increased testing, executing recalls and incurring expenses on the performing company’s time and money, or attempts at various levels to restore customer satisfaction. The cost of non-conformance retraces its roots to the cost of quality examples on lack of adherence to existing policies.

Summary

Therefore, middle management focusing on delivering products or projects, whether they operate through traditional or agile approaches, should evaluate the cost of non-delivery and cost of non-conformance to ensure that all these waste producing efforts are eliminated. Management is obligated to monitor these patterns that lead to the management debt like the technical debt. Only when this management debt is controlled, does the concept of efficiency grow with the seeds of cost of good quality. 

References

Arnheiter, E.D. and Maleyeff, J. (2005) ‘The integration of lean management and Six Sigma’, The TQM Magazine, 17(1), pp. 5–18. 

Carr, L. P. (1992, Summer). Applying cost of quality to a service business. Sloan Management Review, 33(4), 72.

Scott, R.W. (1981). Organizations: Rational, Natural, and Open Systems. Englewood Cliffs, New Jersey: Prentice Hall.

Sutherland, J., & Bennett, B. (2007). The seven deadly wastes of logistics: applying Toyota Production System principles to create logistics value. White paper, 701, 40-50.

Managing others: Four Simple Powerful Questions

I was recently invited to be part of the expert panel with EcoCar 3 in Natick, Massachusetts. It is a college level automotive engineering competition that challenges 16 universities from across North America to reduce the environmental impact of vehicles. It’s a major workforce development initiative that seeds the auto industry with thousands of engineers, business leaders and communicators and we’ve added in a new project management track!

Among the numerous questions asked of the panel, one question that really struck a chord in me was the question on how to engage a team member as a project manager. Now, this topic has been a burning question for me because the most important task facing any project manager, or any manager is getting work done through other people. The principle of emotional intelligence is at the epicenter of leading others. In my doctoral thesis, I studied the relationship between emotional intelligence and various types of leadership styles concluding that transformational leadership was found to be critical for project manager success (Rajagopalan, 2009). Subsequently, I continued to explore using qualitative research interviewing several senior representatives across many industries validating a framework called TONES for middle management transformation through project management (Rajagopalan, 2014).

Synthesizing the ideas again that the panel reaffirmed during the panel discussion, I present below four critical questions. These are:

1. Can you do the task? 
2. Do you want to do the task?
3. Do you have time to do the task?
4. Is this the best you can do to complete this task?

I have established and managed a PMO in a professional service setting and in a life-sciences setting. Further, I have delivered a few projects and programs - some platform level and some client driven projects and I will explain below the purpose behind these questions.

1. The first question focuses on unearthing the true desire for an individual project team member or a project manager in the PMO. If the person doesn't have a desire to accomplish any task, then, no amount of motivation can help. 
2. The second question focuses on addressing the fear factor. The fear may arise from a fear of failure or fear or uncertainty. In such cases, if the person wants to do this but has inhibition, I intellectually stimulate the person on why they want to do the task. 
3. The third question focuses on creating the bandwidth. Sometimes, the person may have too much going on to devote adequate time to complete the task. This question raises what needs to be stopped to free up time required to accomplish this task. 
4. Finally, the fourth question focuses on continuously monitoring progress, motivating and energizing the person to create a stretch goal to raise beyond their own limits. 

Engagement is all about making one feel important and helping them raise above their own assumed potential. Creating this engagement is the seeds for leadership. In getting projects done by people, every project manager therefore needs to demonstrate this leadership.

Thoughts?

References
Rajagopalan S. (2009). Relationship between emotional intelligence and transformational, transactional, and laissez-faire leadership styles of information systems project managers in virtual teams. Dissertation Abstracts International (UMI No: 3359539).

Rajagopalan, S. (2016). TONES: a reference framework for identifying skills and competencies and grooming talent to transform middle management through the field of project management. International Journal of Markets and Business Systems, 2(1), 3-24.

Project Management is a life skill

In one of the blog entries earlier, we had discussed the need for mindset change for project management. If we truly understand the principles of project management, we can appreciate how relevant this skillset is in managing one’s own life. This discipline is perhaps the only pervasive profession that has tight coupling as a life skill.

For instance, let us evaluate how the ten core knowledge areas espoused by the Project Management Institute are integrated with the circle of life using an example of planning a vacation. These areas involve managing time, cost, scope, integration, procurement, human resources, communication, risk, quality, and stakeholder. When we are planning to go on a vacation with our family, we plan how many days we can go on a vacation based on the number of days available from our work. Depending upon whether spouse and children are joining, we engage with additional stakeholders at School and integrate our activities around time. Every activity that we plan during the vacation is scoped out by the amount we can spend on the vacation and the risk tolerance to adventures we can engage in. 

We also engage with multiple types of vendors to book our travel and hotel arrangements. We continue to engage several people in evaluating the vacation spots and activities that we can do to ensure that the value of the time and money spent is of acceptable quality. Finally, we manage several other activities such as taking care of bill payments, watering the plants, taking care of pets, preparing transition plans at work by communicating with the involved stakeholders. Now, is everyone traveling on vacation a project manager? However, as you can clearly see, these skills are still essential outside of the project management profession. Is there any reason why we shouldn't call these project management skills critical life skills? 

The significance of project management principles outside of the project management profession is not new. On May 4, 2013, the Chicago Tamil Sangam staged a historical play, “Ponniyin Selvan” in the regional Tamil language. Centered on a course of events that took place around the 11^th century Chola Dynasty in ancient India, staging the play presented several unique challenges that were overcome by applying some basic project management principles. Each of the following activities were considered interdependent projects that was coordinated as a large program with several milestones, conference calls, demos, rehearsals, and marketing demystifying how these life skills were executed by many non-project professionals. 

As a result, the principles of agility can apply much beyond software development (Rajagopalan, 2013). In fact, the Agile Manifesto shouldn't have even said "Working Software over Comprehensive Documentation" limiting agility to software development. It shows the lack of diversity in the Agile Manifesto contributors from the application of agility beyond their background domain knowledge. For instance, imagine if we had said "Working Products over Comprehensive Documentation". The product can be replaced by any benefit that could be translated into value!

1.    Preparing rich costumes, jewelry, and artifacts to differentiate the Emperor, the Kings, Queens, Ministers, and workers that required coordinated efforts to identify the needs among the actors, procure items necessary from India, and get them shipped from India.

2.    Identifying the needs of the auditorium based on the play requirements, distance, transportability and audience needs including law and order maintenance.

3.    Designing several high-end artifacts that were transportable with easy assembly, such as preparing backdrops suitable for the play, two boats that moved on the state, a ship with effects to display shipwreck, a palanquin as an entry point for the character, and pillars establishing the authenticity of the 11^th century.

4.    Rehearsing the play spread over five volumes perfecting dialogue delivery, enunciation of words, clarity of voice projection, light cues for various spots on the stage differentiating progress of characters and events through various backgrounds, preparation and coordination of musical clues, singing and dance choreograph appropriate to the characters, body language clues collaboration such as when to pass the message card or the crown, how various characters should see during critical scenes, 3 full length exams including a daylong marathon practice sessions.

5.    Advertisement and marketing efforts on social media, press, and soliciting appreciation from prominent external representatives, such as the President of India, increasing the reach.

6.    Subsequent preparation for the main event date with food and supply for the crew, makeup needs, and transportation of goods, stage preparation, and coordination of light clues with the auditorium crew that didn’t speak the regional language, backstage line up of cast during the play informing what scene is in progress.

7.    Addressing challenges for audience lineup, food distribution, parking lot and law & order challenges on the day of the event.

As an extension to the change in mindset on what the misconceptions around project management, let us arise to learn the tools and techniques recommended by this discipline so that we can enhance our own quality of life as well as the voluntary community efforts several of us support. In the next session, we will discuss further on a unique framework from my post-doctoral pursuit of how we can focus on what we need to learn. 

What are your thoughts? Please share and spread the knowledge.

References: 

Rajagopalan, S. (2013). Agility outside of software development: A case study from a theatrical play. https://agilesriram.blogspot.com/2013/05/agility-outside-of-software-development.html

Servant Leadership starts with forming a habit to spread the knowledge

I was volunteering at the #Agile2016 conference this week in Atlanta, Georgia and had an opportunity to support another volunteer friend who was trying to organize an open space session. What was so impressive was this friend's willingness to get over the comfort zone to get in front of a crowd to facilitate this session with the only goal of creating a stickiness of the information gained from attending the conference to others. It was so wonderful to see how this friend exemplified servant leadership forming a habit to facilitate this session.

Marshal Goldsmith (2007) published a classic book where he advanced 20 habits for fast forwarding one's career by identifying habits that may be bringing themselves down creating trust erosion in the team. These behavioral traits may be in our own blind spots that we may easily fail to recognize how we are sowing the inappropriate seeds for our own professional growth while simultaneously bringing the team down. Joshua Arnold (2016) referred to some of these behavioral traits as HiPPO (HIghest Paid Person's Opinion) in one of this presentation at the Agile 2016 conference. Readers are advised to check this classic to get more insights.

It was a classic example for me to see in action how one individual took the initiative to form a habit not only to benefit from his own reading of a classic book but also push the individual limits to get over the stage fear because of the belief that there was something he had the world should know to benefit from. Now, servant leadership is exactly that - leading with others in mind encouraging the drive to excel, acting with humility, and strategically advancing long term benefits over short term quick wins.

This friend proposed the idea at the open space session providing an elevator pitch creating an interest for about a dozen people as he described the 20 habits creating an activity for people to form a group and select one of the habits that resonated with them in groups, create visual images of these habits, and identifying strategies on the impact of this habit and recommendations to eliminate this habit. The amount of time this friend spent at evenings and nights to form the elevator pitch and create stickiness for anyone that may come for his open space session applying the techniques suggested by Laura Powers (2016) really hit a homerun as the attendees to the session appreciated the new packaging on these habits as they emphasized how this session helped them. I was so glad to be part of supporting him in his endeavors.

As I continued to support this friend in this session, I really renewed my own interest in the coaching of such down-to-earth individuals who not only try to improve themselves but attempt to leave the world in a better place than they found it by avoiding excuses. As Kish (2016) and Jurgen (2016) pointed in the various leadership stages of genius tribes and managing for happiness respectively in their keynote address, it is the knowledge that we gain from such selfless individuals and their friendship.

What are we doing today to get ourselves out of any comfort zone that we have encapsulated ourselves in advancing the great experience and knowledge that we have gained? Servant Leadership is a lot bigger than teaching someone to fish! It is teaching someone to serve society by creating a community pool and teaching everyone to be self-organizing and self-sustaining. It is applying leadership beyond the individual, team, and the organization. 

Reference

Arnold, J. (2016). How to train your HiPPO.  Atlanta, GA: Agile Alliance.

Goldsmith, M. (2007). What got you here won't get you there. New York, NY: Hyperion Books.

Kish, C. (2016). Leadership for genius tribes. Atlanta, GA: Agile Alliance.

Jurgen, A. (2016). Managing for happiness. Atlanta, GA: Agile Alliance.

Powers, L. (2016). The neurology of learning: Your brain on agile games. Atlanta, GA: Agile Alliance.

Agile or Traditional - Productivity Management still has basic roots

Having managed a few initiatives in both agile and traditional settings, I often find people thinking the agile culture enhances productivity many times over the traditional thinking. The principles of collaboration, limiting work in progress, lean thinking over scope, and focusing on value generation may lead one to think that agile is much better than traditional. Still traditional approaches to management don't mean that these processes should be avoided to sow the seeds of productivity. Agility is, in the end, only a mindset to managing productivity towards value generation. In my experience, I have found a few techniques that have withstood the test of time to produce predictable productivity in any team.

1. Manage meetings
There is a lot of practical literature around how to run effective meetings. Instead of going into microscopic details on meeting management, can we not focus on ensuring that every meeting has a clear outcome to accomplish at the end of the meeting? Whether it is a 15-min or a daylong meeting, having a clear outline of planned outcome will establish evaluating the necessity of the meeting in the first place. Not having a meeting unnecessarily or accomplishing meeting objectives earlier releases so much time that could be used for other productive tasks.

This is where agile thrives because it timeboxes all ceremonies and avoids meetings not necessary. Project and Program Management can also apply the same techniques.

2. Correct your course
Whether it is running meeting or managing the client, things don't always go the way you plan! So, plan for course correction? What's the point in all this "Failing to plan means planning to fail" when we fail to apply it in principle! When a meeting goes on a tangent, correct your course by bringing attention to your outline. When customer requests come out that emphasize lack of understanding or you get a project where you don't know the underpinning the technology, make course corrections yourself by taking an initiative to learn the technology!

In the world of Khan academy, Plural Sites, Course Era, Open2Study, Bright Talk, and so many other MOOC - not to mention YouTube or Vimeo - there is plenty of information available already for people to gather information! So, correcting your own course is totally on you and not doing so is taking the team's time away! Be warned, however, that not all information on these sites is correct and credible. Do your own research!

Here is also an approach from Agile where there is retrospective at the end of every iteration! Did traditional approaches ask not to have frequent lessons learned sessions? Absolutely not! It is a restriction that project management forced themselves on and the management failed to react to it. In other words, they chose to learn from the lessons and hence succumb to failure! Furthermore, retrospective is the last moment to capture lessons learned in that iteration. Lessons are learned every day and captured every day! 

3. Focus on Training on "Done" criteria
Having a constant baggage on the trunk creates so much drag in an automobile which slows the automobile and burns unnecessary fuel! That's why we don't drive - at least technically - with unnecessary baggage, right! Doesn't that principle teach us to focus on getting tasks completed! Coming from lean management philosophy, it is a principle of waste in over-engineering anything to the point that it is not getting done! So, project management can extend these principles to apply simple heuristics in managing their WBS or have user stories that apply the INVEST principle.

In my experience, I have always applied the golden rule of no task having a duration longer than the risk that I can live with the task completing. Most often, no tasks are longer than 40 days and some work package are always delivered every two weeks. So, milestones are not 3 months apart! Such thinking still applies earned value principles to make course corrections if a project slips!

Here is where the INVEST principle from agile comes to help where every user story is independent, negotiable, valuable, estimable, small, and testable! So, don't add tasks just for the sake of adding and use the hammock tasks productively.

4. Establish Stretch goals
No matter how much one knows, there is always room for improvement! This is one of the reasons change management principles advocate continuous improvement. The self-organizing theme behind teams in agile setting really ensures that team members are adequately skilled cross-functionally to pick up other people's task to support the sprint commitment! In a traditional setting, we create unnecessary layers. Every team in a traditional setting should have a stretch goal to learn another team's work and practice. Not only does this avoid central dependency on another, but it also helps appreciate the tricks of trade and appreciate the service level agreements and standard operating procedure enhancing adherence to protocols. It also lets creative juices flow as one challenges the status quo to do things differently! Only by learning more does an individual become part of a group and evolve to be a self-organized team.

5. Use the tools of communication effectively
Although we all appreciate a wrench and hammer have their distinct purposes, we also realize overly abusing the tools for the wrong purposes damages what we are trying to accomplish more than the tool itself. The same analogy goes with the tools. I wish we could monitor the use of the "Reply to all" button that creates so much email for an organization. People reviewing the emails out of sequence, replying to them in random order understanding parts of pieces, and eventually ignoring it will only cause so much productivity loss - time that can be used for other productive tasks. So, learn to manage by walking around, collaborating using better tools, and avoiding creating so much electronic dialogue that provides no clearly documented decision making.

In my experience, these simple techniques have helped build constant productivity regardless of the approach. In the end, what matters is only the results.

Thoughts?

Agile needs to understand and focus on agility more

Over the last few weeks, I overhead a few practices such as the following while claiming to practice agile.

a)       Not finding the tasks in the sprint backlog for sizing the user story

b)      Evaluating the definition of done during almost every sprint

c)       Focus on the sprints and lose the value not delivering on committed time

d)      Not factoring capacity into account in a velocity driven planning

The major focus of agile is on maximizing value to the customer. This is stated as, “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” To accomplish that goal, it is imperative to ensure that we exhibit agility rather than claim to practice the so-called Agile paradigm. When the focus is on this value maximization to the customer, how could the above practices that fail to add value to the customer be considered agile practice?

Maximization of value means within the agreed timebox, the team self-organizes to add the appropriate tasks. The scrum master acting on the team’s behalf needs to hold the definition of done articulated ambiguously by the product owner. Similarly, the product owner needs to be held accountable to the larger committed timeline to the customer not losing focus on the slips in the timeline due to losing velocity in every sprint.  The scrum master needs to hold the product owner responsible for capacity planning in a velocity driven team rather than a commitment driven team.

If the principles recommended above are not upheld, then claiming to be agile is an understatement. This is because the maximization of value delivery with a focus on customer is falling apart. Some of the root causes are the following:

a)       Thinking that a team is agile just because of the use of a specific tool or adoption of a specific recommended ceremony.

b)      Merging the crucial roles of scrum master and product owner in one person who keeps neither role in check.

c)       Addition of new team members not sharing the same norms disrupting operating rhythm.

d)      Allowing the flexibility to let the team not meet the required commitment because it can always be picked up in the next sprint.

Going to the basics, if the focus is on value delivery to the customer, then, it is important to not lose the focus of time, scope, quality, and cost and the risk of non-delivery on these elements. Increasingly, as agile gains mainstream focus, it is indispensable for the agile team to understand these considerations and not just adhere to agile terminologies. Only when one understands these principles can one appreciate when to stay agile, when to adapt practices, and when to recommend going with traditional approaches. 

Project Management – Mindset Change

I recently published an article in a Chicago Tamil Sangam's newsletter in my native language, Tamil on the change in the mindset about project management. Based on requests received to see this message translated in English, I am posting this blog entry.

Once upon a time when someone didn’t get a job the people recommended those to get a computer engineering job. Similarly, the prevalent thought of project managers among today’s workforce is that these project managers can’t do anything other than updating tasks in the project plan. Although the experts familiar with project management profession can laugh and ignore these comments, these comments are regrettable when the experts think these comments deeply.

The Project Management Institute describes this profession suggesting that project managers should exhibit multifaceted skills to enter any industry. If you check out the responsibilities of the roles such as the healthcare software engineering, retail database administrator, or financial QA analyst on the Internet, do you think one can get these jobs without the required experience for that job? Even if one gets this job, can one continue to retain that job without keeping skills current? I am sure you know the answer.

Like these jobs, the project management profession also has been mandating the project managers to possess the specific domain knowledge and basic technical skills for a long time. Despite that, why do people feel the way expressed above about this profession? There may be many reasons for this. However, one important reason is the project manager’s lack of self-initiative! The resulting lack of attention to details leads to team members spending their time in unnecessary meetings, correcting customer complaints, and collecting required documents eroding trust and earning aversion on the project manager. These mixed feelings about the project managers manifest as a mocking smile at the project manager’s incompetency.

Analogous to the dialogue from the very popular Tamil movie, Parasakthi “Whether our voice is heard in heaven or not, it should be heard by the management,” the Project Management Institute also introduced several changes through the Talent Triangle. This requirement mandates the project manager to continuously improve their technical project management, strategic business management, and leadership skills potentially leading to the losing their certification when these skills are not maintained.

Many of you may be a project manager, member of a project team, hiring managers, or their friend or family. Your cooperation is also required to change this mindset about project management. If you are a project manager, begin to participate in the local chapter meetings and join advanced classes to improve your skills and competencies. If you know a project manager, create volunteer opportunities and encourage project managers to practice their skills. When such attempts lead to making the project managers better at their professional skills, you will also reap from the benefits of the projects managed successfully. So, let us stop feeding the earlier thoughts, think of what we can do and act on it!

Reference
Project Management - Mindset Change (2016, April). Palagai, 1, 8-9.

Agility in Negotiation: Focusing on the “Why” behind mixing strategy with scenario

Negotiation is a strategic and learned skill. Whether one is negotiating terms of compensation for a gainful employment, partnering with a vendor, or evaluating merger or spin-off arrangements, the principle of negotiation is a critical managerial skill applicable for individual contributors or managerial roles. The agile principles of iterative and incremental are equally applicable in this strategic negotiation. Two simple ways this agility can manifest in negotiation turning out to be strategic involve in getting back to the root cause before taking a collaborative or assertive stand and having the self-organizing mindset to adapt the negotiating style.

For instance, consider that a negotiator always has a predetermined style. Within the organization, when negotiating for a resource or budget such as the distributed negotiation, the predetermined style makes the person too predictable. Such a predictability provides a competitive disadvantage for the negotiator as the other party can deftly predict the questions and be ready with the counter responses. Agile principles recommend the self-organized team where the team determines how work executed after the user stories are explained by the product owner. The team adapts to the operating rhythm within every release and sometimes within every sprint as not all sprints and releases are the same. Similarly, not all negotiations are the same and having an adaptive agile mindset is critical for the negotiator as no two negotiations are the same.

Let us look at the root cause. The goal of the negotiator is to get to the basics of why the other party wants to engage in a negotiation. Trying to understand the fundamental interest takes precedence over taking a position based on power or seniority. This position is the outcome of what the negotiator wants in the negotiation but to make the negotiation successful and satisfactory the focus is on the “why.” Now, lean management principles have come to the rescue here with the 5-why approach to not taking the immediate statement at face value and questioning them further repeatedly thereby developing an incrementally better view of the root cause.

Prior to coming to the table for negotiation, there needs to be just enough research done on the problem. This research gives you the best alternative to negotiating agreements (BATNA). While the interest is to have a win-win solution, often negotiations may end in “win some” – “lose some” situation. Knowing the BATNA helps with the zone of potential agreement (ZOPA) so that agreement is made on what is necessary (Opresnik, 2014). Otherwise, one can be tempted and led into the agreement trap! 

As you can see, a strategic negotiation therefore is rooted in adapting the skill to the scenario much like the project manager adapting to the demands of the new project and understanding the requirements more than a solution. 

References

Opresnik, M.O. (2014). How You Learn to Successfully Negotiate. In: The Hidden Rules of Successful Negotiation and Communication. Management for Professionals. Springer, Cham.

Project Closure – The final frontier!

I recently observed comments on project management not updating the project plans and performing administrative closure on a project that was part of a larger program. It prompted me to think how critical the processes related to closure when all scoped deliverable of a project is completed. There are many reasons for project closure even when the book of accounts itself needs to stay open such as being able to invoice against the other projects making up the larger program. However, the most notable are evaluating the project profitability, lessons learned, and customer satisfaction which are integral to the organizational project assets.

Listed below is some of my own experience in performing proper project closure and the project plan is just a gentle reminder that this is a responsibility of the project management.

1. Has the contracted scope of delivery been met? If not, why?
2. How efficiently were the project objectives delivered?
3. How effectively did the project stay on schedule? If not, what contributed to the delays and what processes need to be in check to avoid future schedule slips?
4. How well did the project management proactively forecast changes and adjust the estimation process?
5. How satisfied are customers and project stakeholders?
6. How did the actuals compare to the final baseline plan?
7. How did resource availability changes impact the delivery to adjust for capacity planning?
8. Did the team work together effectively?
9. What individual contributions positively or adversely impacted the project’s quality? How were performance expectations managed?
10. What attempts were made to strategically manage the customer?
11. Did any work start late and if so, why?
12. What improvements must be made on an individual, team, and process levels to positively impact future projects?

Thinking from an agile or lean perspective, the definition of ‘done’ includes the completion of the work planned. Including a task to be completed in the plan and leaving it incomplete shows the lack of agility. Even from a plan driven approach, the administrative closure on a project is a checklist guaranteeing completion of deliverable against contracted scope, documentation of performance results, recognition and performance evaluation of team members, updates to risk register, and release of resources from contingent actions. 

As the saying “When the going gets tough, the tough get going” goes, if the lack of time is the reason for not updating the project plan and performing the administrative closure, then not doing so is going to take more time when such essential knowledge is not disseminated. If processes are the bottleneck to performing this closure, then, these processes are at best questionable towards continuous improvement.

In the spirit of how Star Trek introduced Space as the final frontier, I view Project Closure as the final frontier to ensure knowledge capture to make course corrections in the existing projects for future projects to benefit immensely. Whether practicing agile or plan driven approaches, learning from projects is the origin of learning organizations. 

Thoughts?

Career Management starts with managing oneself for competencies required for the new role

We must all recognize that time has moved well past the industrial revolution into digital explosion. Let us all look around and we can see that new industries have surfaced, and new business models have evolved. Yet, how often can we all say we have developed new skills and competencies to compete not obsoleting ourselves. We are all still looking for promotion and increased pay but has anyone refused a promotion because they need to sharpen themselves for the new competencies required to succeed in the new role. I would like to share in this blog a few simple techniques that I have found working well as well as observed others do to managing the career.

1. Establish your brand by thinking strategically big

Simply put, in your absence when people think of a new structure for the organization, a new venture to consider, or a bigger problem to solve, will many people think positively of you to be the ombudsman? Here are a few powerful questions to establish your brand.

·         What quantifiable results have you consistently produced in the current organization?

·         How much does your organization remember of your previous work experience when a challenge arises?

·         What references can the customers internal and external to the organization provide consistently that elevates the perception of you?

2. Come to terms that you are a salesperson for your unit, product, and organization

This was difficult for me to relate to! Evolving from being a software engineer to a project and program management career, I never conceived myself to be a salesperson until I heard in a networking event on how I was referring attendees to a local restaurant that I have frequented! We may not know that we are not a salesperson but when we interface with the other units within the organization, we are selling the quality in code, good design in the architecture, positive returns on the product features, and solutions through out products for customers! Some questions to ask ourselves to expand our competencies are:

·         What new business problems will your existing skills solve for the organization or customers?

·         How much do you know what new competencies are required for your growing organization?

·         Given the same pay and terms and conditions, are your skills on par with the consultants in your discipline?

·         What business value have you added beyond your current role to stretch yourself out of the comfort zone?

·         How much reputation precedes you among your peers, customers, and employees in your problem-solving skills?

3. Continuously focus on becoming an expert

Too often, people rest in their comfort zone because they have a job or just got one! This is an expectation mirage as what we know is frequently replaced by new information, business paradigms, changes in technology, or tools used in their chosen professional discipline. Every year fresh graduates come to the candidate pool and experienced candidates that amass new knowledge come to the job market. It is inexorable for individuals and management to ignore the competencies required of themselves and of their team. A few ideas to take a pulse check are as follows:

·         What outside organizations are you actively involved in to learn new concepts?

·         What new team management skills have you gained if you are a manager in a balanced or functional organization?

·         What additional skills and competencies have you developed to further your knowledge of your own discipline?

·         Have you been asked to speak or write in journals, trade events, or conferences in your field of interest?

·         What specific challenges does your organization face where you bring expertise to the table from your previous experience without depending on on-the-job-training?

·         Have you been proactively able to challenge the status quo where customers and peers recognize your voice and instituting changes?

·         What opportunities have you explored moving laterally within the organization expanding your cross-functional knowledge and expertise on products, processes, and people in your own organization?

4. Bringing out the best in others

I once heard a definition of success that read, “My success is defined by how soon I eliminate myself.” It struck me so much that I never focus on job security by staying in the comfort zone of siloed expertise. Instead, I focus on employability where I develop others to expand on the paths that I have found or allow them to find a new paths to make things even more productive. This succession planning is critical for one to be unplugged from one’s current responsibilities and be available for the next opportunity that may knock. A few suggestions to consider at this point on this forefront are below.

·         Do you have a mentor yourself to help you see beyond your own blind spots?

·         Do you have succession planning in your individual development plan where you have identified someone and mentoring them to be where they can be?

·         Have you helped someone see the long-term impact of the project that they are working on, the challenge they are solving, or the opportunity they are resolving and its relationship to their own career through the eyes of the customers and organization?

·         What’s your professional life’s mission or philosophy?

No one can entirely predict what fluctuations can change the way businesses operate or technologies evolve. Just like financial institutions say past performance is not an indicator of current or future performance, the skills and competencies that got an entry into an existing role or maintain the existing role is not an indicator of what the organization or industry is demanding. The longer these skills and competencies are not on par with the industry, the deeper the experience gained will lose its significance. So, develop a quest to do your own assessment and wake up to the competition. 

What are your thoughts on these observations? Please share.

Starting the Problem Half solved: Strategic about Successful requirements gathering

In one of the recent round table discussions that I spoke on the differences between traditional and agile approaches, it became apparent to me that there was some disconnect in the notion of what constitutes a requirement. The software development approaches leveraging traditional plan driven approaches to project management focuses on scope planning activities that centers on requirement definition because it is well known that a successful definition of the problem means we have the problem half solved.

Considering the developments in agile approaches to project management where change is welcome even at later stages in the development, the gathering of up-front requirements is often frowned upon. Although the requirements definition may be a daunting task when there is ambiguity around it, value delivery happens only when an attempt is made to eliminate such ambiguity. When client facing members fail to ask powerful probing questions and engage the expertise to eliminate some level of ambiguity, the business goals are often compromised.

For instance, a requirement should at a minimum address what the software must to do satisfy what the users need so that the value is maximized, and benefit is realized. On the contrary, if the requirements are conflicting and attempts made to eliminate ambiguity are thwarted, then neither the traditional nor the agile approaches to software development will benefit. As the movie, Apollo 13 calls its mission at the end, such requirement gathering from the beginning can only lead to "Successful failure."

Readers are directed to check out an interesting video at this point to gather some insights into the incomplete requirement gathering This video is on youtube at https://www.youtube.com/watch?v=BKorP55Aqvg. What went wrong here? A few thoughts are as follows. Share your thoughts.

• Is starting immediately with a “No” a good approach?
• When trying to ask what the end result will look like, is attempting to over-please rather than understand the business goal appropriate?
• Is both the client facing person and the project manager on the same team as the expert?
• Were any attempts made to negotiate for an acceptable best alternative?
• Is this project setup to succeed?
• Is this a productive meeting?

What powerful questions can you add to ensure that redefine the requirements correctly? Stepping outside of this video into our own projects or products, what additional questions can we ask to understand the client’s requirement and the reasons behind the requirements better to position ourselves for success?

Negotiation: Tactical Conflict Resolution to Strategic Transcendent Eloquence

Managers and leaders can always recognize that they may not always get what they want when working with stakeholders. Whether it is working with external vendors and clients or internal business units and employees, negotiating for the right resources, contractual agreements, time, cost, scope and even risk is omnipresent in today’s business environments. The fundamental reason for negotiation is to agree on a term that allows both parties in the negotiation to perform better or produce something on relatively better terms than in the absence of the negotiation agreement.

Those that have worked on negotiation may very well know the common techniques like issue resolution, democratic dispute resolution, bargaining, and litigation. But some may relate to the term phrase best alternative to a negotiating agreement (Fisher and Ury, 1981). Depending upon the root cause that led to a disagreement or conflict, the negotiation may have to morph from simple dispute resolution to a transcendent eloquence. For instance, the discussions such as negotiating for an extension to a project or salary negotiations for a new job may involve evaluating the BATNA from the following areas:

• Opportunity cost of the existing status quo relative to the alternative arrangement
• Impact of the alternative arrangement on the immediate needs that caused the dispute
• Timely feasibility of executing the alternate arrangement
• Risk of the alternative arrangement not providing the promises relative to the status quo
• Evaluating the risk profile and thresholds of the appropriate stakeholders who can be enablers of the best alternative 

However, when the disagreement is no longer simple and arises due to differences of opinions that are both equally valid and respectable, then the resolution to such disputes may involve strategic negotiation techniques like transcendent eloquence. This is a technique where the parties to conflict themselves develop a framework for understanding and addressing their conflict (Freeman, Littlejohn, Pearce, 1992). This approach fosters a constructive dialogue evaluating the strategic fit of these incompatible yet morally valid disagreements. Such beyond-the-normal discourses need to philosophical, comparative, dialogic, critical, and transformative, says Pearce and Littlejohn (1997, p.157). While it is generally recommended to apply this technique in extreme scenarios like military negotiations and high corporate decision-making involving spin-off, merger, etc., this technique can also be beneficial for middle management to exercise their strategic skills.

The philosophical nature of this approach looks beyond the root cause analysis to evaluating the fundamental belief system that gives raise the conflict. Such a journey can encourage both parties to educate themselves on the paradigm shifts in the industry to think outside the box to raise the bars on performance measures. Similarly, the comparative nature of this approach attempts to resolve differences of opinions arising from incorrect frames of references, such as those in differing geographical cultures or vendor relations where each party may have different operating rhythm in software development. As a result, both the parties may establish common patterns of language that serve as the framework of reference on the roles and responsibilities moving further beyond eliminating conflict to addressing productivity.

The dialogic nature of transcendent eloquence engages active listening steering towards breaking a new ground by using powerful questions towards exploring the root causes. Both parties are now engaged in not only establishing common ground but collaborating towards alternative generation that neither party could have arrived at working alone. On the contrary, the critical nature of this technique applies the concepts of power and influence each party can exercise in implementing the solution by evaluating the strengths and weaknesses of the espoused solutions to ensure that the best alternative is not only a strategic fit but also is rooted on operational efficiency promoting changes that also need to be provided to the appropriate managers and leaders in successfully implementing the solution. 

Finally, the transformative nature looks beyond the conflict into applying the alternative agreement and seeing if the costs of winning justifies being in the game. In other words, should we even be engaged in resolving this situation? For instance, if continuous investment for a product losing its market share may be justified to some extent but if the massive adoption of a new technology is acknowledged in the macro-environment, should alternatives to sustain the product be even considered?

Have you applied any of these approaches in addressing your challenge? How do you think you can apply these negotiation techniques in addressing your challenge?

References

Fisher, R. and Ury, W. (1981) William Ury. Getting to Yes: Negotiating agreement without giving in. 3rd ed. New York: Penguin Books.

Freeman, S.A., Littlejohn, S.W, and Pearce, W.B. (1992, Fall). Communication and Moral Conflict. Western Journal of Communication, 56, 311-329.

Pearce, W.B. and Littlejohn, S.W. (1997). Moral conflict: When social words collide. Thousand Oaks, California: Sage Publications 

Project is a verb in Project Management

Project Management is one profession that has grown from practice. While education and some experiences were the only prerequisites for one to be considered a project manager, the surge of accidental project managers has really led to the loss of the fundamental skills and competencies of a project manager. The project management role is a conduit to projecting a voice backed with action managing and leading change using projects as a vehicle in managing all areas of project management.

Therefore, I view “Project” as a verb and not as a noun. This is one way to make project managers move much beyond cookie cutter project management. Each character of "Project" therefore defines the competencies expected in a project manager.

• P - Passion for people. Project management is all about people management. This is where the transformational leadership elements of a project manager is displayed.
• R – Resourceful around Risk management. Seeing proactively the risks and managing them by maximizing opportunities and minimizing threats  
• O - Organized around self to manage all aspects of the project. As the saying goes, if you can’t manage yourself, you can’t manage the people that do not work you in the project.
• J - Justified in constant review of resource utilization including both the human and non-human resources keeping in mind the total cost of ownership on the project managing scope and quality
• E - Effective in leading change seeing it as a vehicle to improve scalability and as a liaison to other business units within the performing and client organization
• C - Collaborative in bringing ideas together letting the individuals become groups and then evolve as teams to support each other
• T - Trustworthy to transform people’s career. This completes the cycle of project where one’s passion for people makes them servant leaders.

Abuser Stories:What shouldn't the software do?

The general tendency of the requirements document has predominantly focused on what the software should do. In project charters and scope control documents, sometimes we also write what features will be out of scope. The UML diagrams and use cases discuss how the classes should interface, and modules should interoperate, for instance. The agile paradigm discusses persona approaches drilling down DEEP property for describing backlog features and INVEST principle elaborating on the characteristics of a user story. Even test cases that focus on negative testing use a requirement traceability matrix to the requirements limitedly testing the functionality of what a system shouldn't do.

But, when a system is hacked or inappropriately accessed, the loopholes rests on the inefficiencies in how the system was designed to allow such loopholes to exist. So, how do you avoid these vulnerabilities so that the hacker doesn't exploit these "working as designed" gaps?

While volunteering at the Agile 2015 conference, I chose to attend a section on Abuser stories by Judy Neher from Celebrity Technical Services. It was a great session introducing the concept that a persona of a hacker or disgruntled employee could potentially have a malicious intent to deliberately break the system. The speaker suggested describing user stories that specifically could break the system or expose the system for malicious intent. The participants in an activity gave examples for a simple user authentication such as the stringent password recycle policy, the use of a double password and picture identification, the use of external devices such as phone, email, or mobile texting to use tokens for validation within a short timeframe before the account is locked, the creation alerts for maintenance for incorrect and frequent access to multiple accounts, the enforcement of HR exit policies on employment dates before the role based access can be authenticated, the validation of human versus robot logging by tracking the speed of password entry, etc. Imagine having such stories to bulletproof the system against malicious attacks on standard user stories and have automation capabilities to constantly check for these loopholes.

I am sure one would say that this would add more time to the scheduled release or limit the stories written per iteration/sprint. Of course, like non-functional stories that add some time, the abuser stories also will add time. The need to develop hunches on the type of regulations in the industry, the type of technical platforms used, the time to market considerations, etc. However, the question shouldn't be whether to do them or not but when to do them. If we fail to do them, we are increasing the technical debt. A couple of alternatives are to dedicate a sprint or a portion of every sprint to address these abuser stories.

I really think this is an important component of combined technical and product ownership to ensure we see the persona of other types of users and see the system from that view. As good project managers turn assumptions into risks and control quality, the technical and product owners should be accountable for products that preclude vulnerabilities by design. Abuser stories are a great start. Don't you think so? Share your thoughts.

References

Neher, J. (2015). Abuser Persona. Agile 2015 Conference. 

Attention or Time Management

Flying over India returning from Mumbai to Chennai, I was browsing the Jet Airways magazine. Often filled with travel recommendations and shopping suggestions, these in-flight magazines have only created a browsing pleasure. But this magazine had a topic on achieving more with less perking my interest to explore.

It was an interesting read as the article began discussing how  time management pretty much shouldn't be the focus of smart managers. Instead, the article focused on attention management. Based on the time of the day, people can manage difficult tasks that require deep thinking, strategy, etc. when their attention to detail is at its peak. Then, as the energy winds down, their attention takes a deep dive. This time should be used for tasks that require less critical thinking.  Between these extremes is the reactive attention seeking time zone that should be used for other tasks that require a balance of the two.

I agree that it is a good idea and that tasks require different levels of thinking. For instance, planning for the project, evaluating strategies to grow accounts, or grooming the product backlog with new features based on the market and reactions from customers and users require thinking different from task or resource management.

However, the article said the urgency of the tasks shouldn't be a criterion for attention management.  This begs some thinking as depending upon the role of an individual manager, the urgency of the task, such as a grieving customer on the phone, an infrastructure deficiency leading to business continuity management, or a delayed or poor-quality work impacting deployment readiness of a project is not something that can be ignored.

The earlier approach on using Scrumban to think a couple of steps ahead and plan can be combined with attention management to better compartmentalize take at hand and energy/attention requirements to better manage productivity.

Thoughts?