Challenges of Managing Projects Involving New Technology

Projects involving use of new technology present some distinct challenges for the project manager.

As part of project initiation, explicitly distinguish between technology that is only new to your enterprise versus that which is truly new technology, perhaps bleeding edge. As an example of truly new technology, consider Hadoop about 2009: high risk, limited knowledge base, unclear path to solution, lots of unknowns. Especially for those cases, one needs to evaluate up front the tolerance for risk and for failure in the organization.

If mainstream culture in the organization is not well suited for such endeavors, a possible approach is to isolate them, moving them to an entity with a more appropriate culture, that of a Lab or Skunkworks.

Be aware of cognitive biases, and impact on decisions, especially of those in the C-suite, such as hindsight bias:”I knew all along that….”. This may surface as the project progresses, particularly as it encounters significant obstacles.

The business value should be clear, both for complete success and for partial success. How does this effort fit within the company’s strategic direction, both overall and in terms of technology. Estimate what degree of expertise will be needed for this to bring value. What is the impact of failure, and if there is still some return of business value from that failure.

Determine what’s in scope, and where possible, explicitly note what is not in scope, while allowing for discoveries along the journey. Agile forms with their iterative approach may have an advantage over more traditional (waterfall) methods. Waterfall tries to capture all requirements up front, so may have difficulty when faced with lack of clear solution and high number of unknowns.

As features to be implemented emerge, acceptance criteria need to be defined, including definitions of partial success, or of minimum viable product (MVP).

In both project layout and architectural design, try for modularity. Consider use of prototypes where feasible; in software, consider approaches as Test Driven Development (TDD). Try to minimize external dependencies. New tech has enough risk built-in, without adding to it from external sources.

Risk management is always key to project success, but more so when new technology is involved. Include the people element in risk, e.g., staff turnover as well as burnout. Note that as subject is new, that the knowledge base will change during the life of the project.

Watch out for regulatory risk and environmental impact, depending upon the nature of the technology involved. E.g., wind farms and migrating birds.

Depending upon the criticality of the project, try using the pre-mortem technique to better identify potential obstacles.

Communications planning needs to include review of that plan when significant obstacles are encountered. Ensure that stakeholders are all identified, and that they receive appropriate levels of communication, Special documents may be needed for stakeholders, to deal with team turnover, and to ensure that what is being discussed is agreed upon Use FAQ’s, glossaries, visual representations. For example, clear and consistent vocabulary used in drone technology, or in cybersecurity work.

Part of the project plan needs to have a means of bringing this effort into the mainstream of the enterprise; not just ongoing support of this product, but of the potential use of the new technology.

There are many more areas to consider, but this should be a good starting point for project management of new technology.

Advertisements

Agile for Budgeting

Agile (Scrum in particular) is a framework for Product development, not just software development. It’s been successfully used for a wide variety of products, from medical devices to ad campaigns.

Let’s consider an organizational budget as another form of product, and explore if Agile might offer some advantages as an approach. Key among Agile values are embracing change; transparency; inspect and adapt.

Annual budgets are resistant to change, by their nature. While a sizeable portion of the budget might be necessarily fixed, not all of it need be. Some good-sized chunk of the overall budget can be marked as “adaptable”, being altered at some time-boxed frequency during the year, to best meet business priorities at that point in time, by a consistently organized team. Depending upon the organization, its culture and needs, the release of this could be quarterly or more often.

The overall annual budget tends to reflect a command and control culture in most organizations, even in those perceived otherwise. The budgeting typically is one pass, and then consolidated. Instead, try multiple passes, iterating, with transparency of plans between organizational units.

The funds for each item are implicitly the metric for business value; if there are other factors, then this needs to be explicitly stated, and ranking of business value made clear, for each budget item.

If an organization is going through a significant transformation, the budget not only should reflect this, but needs to adapt to changing circumstances along that transformational journey. The environment around the organization will change, and particularly for transformations, malleability is essential for success. Adaptive means agile, not the traditional approach.

note: originally posted to LinkedIn Pulse, Nov. 2015

Agile User Stories and Application as Persona


In Agile, requirements are communicated via user stories.  Traditional user stories use the form, “As a …, I want to …, so that I can ….”.  For example, “As a first time user, I want to be able to create a user name and password, so I can securely do transactions.”   That enables functional requirements to be captured as user features, but still does not address the often critical “non functional requirements” (NFR) in an Agile framework.  NFR are items sometimes associated with infrastructure, such as capacity, scalability, reliability, availability, or security.

One approach to including NFR in an Agile context is to create user stories based upon the application itself as having a role or persona.  For example:

“As an application, I want to be able to process xxx transactions per second, to be able to handle peak monthly demand.”

“As an application, I want to be resistant to SQL injection attacks, so that my transaction integrity remains valid.”

Appropriate acceptance criteria need to be included; phrasing those can be challenging in these cases.

Extending the concept of the application persona further, it can also be used for other aspects of the application, such as user interface or user experience.  Those may fall outside the straightforward transactional features covered by more typical user stories; use it for the more qualitative ones, the fuzzier parts.  The usual guidelines still apply: make the story as granular as possible;  and to include acceptance criteria.  Acceptance criteria can be very difficult to create when one is trying to specify aspects of user experience as quality or beauty.

Taking this further still to the more general case of product development, including the difficult cases of ad campaigns or branding, the concept of the application or product as a persona remains tenable.

E.g., “As a brand, I want to be able to highlight the excitement of using our products, so that I can …..”

Cultivating the Zone

In the zone: usually we think of this state in terms of athletes, or creative artists: musicians, writers, dancers, poets.  Yet it’s not just for individuals, but for teams and groups as well; an example is the hyperproductive IT developer teams, mostly associated with XP and Agile practices.  Psychologists seem to prefer the term, “in the flow”, and that’s how you’ll find it in Wikipedia.

Think of it as an alignment of deep skills and a clear, achievable, meaningful task; a state of resonance between reality of the moment, the task to be accomplished, the skills brought to that situation, and an exceptional focus on that task.

It’s not just highly productive, or good solid work; it’s exceptional, out of the everyday mode of doing.

It’s never guaranteed; no sure recipes for entering into that state.  It cannot be forced.  But it can be encouraged and cultivated, nourished; allowed to happen.  Impediments to it identified and removed.

Some conditions probably necessary to achieve this state are:

  • The person or team is skilled in their field, perhaps deeply skilled.  A sense of mastery, pride in those skills, and some confidence in their use.
  • A bit redundant, that they have to enjoy what they’re doing.
  • The task is well defined, perceived as achievable, but challenging.
  • A high degree of focus and concentration; absorption in the task at hand.
  • This absorption can result in a feeling of being one with the task. The person becomes the work.
  • A feeling of fluidity, less difficulty than normal, performance seen notably above the usual.

How can we cultivate the conditions to help get into the Zone?  We, as individuals, as managers, team members, project managers, setting up an environment that allows this to happen:

  • Minimize distractions and encourage a sense of focus.  For some this means suitable music; for others, quiet; for some teams, something to impart energy. Perhaps a sign outside the team area, “Do not stick fingers in the cage.”
  • Make sure that tasks and goals are well defined and achievable. But don’t micro-manage.
  • Create an environment of minimal worries.  A sense of safety, isolation from threats.
  • Encourage a culture of mastery of the relevant skills, so that the basic tools are extensions of our thoughts. The thought effortlessly becomes the action towards the goal.

Don’t be concerned about rewarding this behavior: being in the zone, feeling that flow, is its own reward.

 

 

Choice is a Gift

 In traditional development methodology, tasks are assigned to the developer, usually by their manager or by the project manager.  In an Agile environment, the team is self-organizing.  Managers accustomed to hierarchical or command and control cultures find this unsettling, almost heretical. But repeated studies (e.g., Forrester) have shown Agile teams to be more productive.  Within the Agile community, one even discusses a team becoming hyper-productive, as though achieving an elevated state of awareness, transcendent.

 My assertion is that giving the developers the ability to choose is a major contributing factor in that increased productivity; furthermore, that this can be applied in non-Agile environments.

 It is not just the selection among different options that is empowering, but the detailed involvement in the decision process.  With that involvement comes a commitment of mental energy, an increased degree of being invested in the outcome.  The ability to choose is by itself a reward. 

 Effective choosing cannot be done in a vacuum.  As a manager, part of your role in giving a team the ability to choose is to make sure that they have correct information, as rich a context as possible for their decision;  where this fits within a larger view.  Your ability to communicate your vision is an essential ingredient in the outcome. 

 One must factor in the nature of the team:  how experienced they are; their knowledge of both subject and technology; their interaction with each other.  The degree of guidance you provide is part of your art as a manager. 

 Trust is key: bi-directional trust. You trust them, but they also need to feel that you have their back covered. Do you trust them enough so that YOU take responsibility for their choice?  If your boss comes asking, it’s still your responsibility.

 Choice can also inspire creativity, options as a gateway to innovation.  You believed the options were A, B or C, but once the team got actively involved in the decision process, they came up with a supersonic rainbow that did it faster, more reliably, and made the users happier.

 As a manager, it takes courage to trust your people and give them the gift of choice.  Reward them with this, do it wisely and well, and don’t be surprised if their excellence exceeds your expectations.