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

Paired Project Management

You probably have seen some of the statistics on project success rates, or more aptly, the rate of the lack of success. The Standish Group’s Chaos report is often cited as one source. There are numerous causes, but one suspects the statistics are even worse for projects of greater complexity.

There are multiple factors to project complexity: the impact strategically or financially to the enterprise; the overall stability of the environment; degree of uncertainty (in multiple dimensions and constraints – from, “is this definitely the right path?” to “will key resources remain”); the number of different disciplines involved; severity of social or legal impact; etc. Far too often, project managers don’t evaluate complexity at project initiation, only realizing the project is of significantly more complexity when difficulties are encountered.

Rule of thumb in planning:
the more complex an undertaking, the more likely any one individual will miss some key element.

One of the interesting practices in the Extreme Programming (XP) movement has been use of pair programming. Two programmers sharing a keyboard and monitor, working together. The typical dynamic is that of driver and navigator; periodically, they switch. Necessary conditions include compatible temperaments as well as cultural support in the team and organization. There are other factors, well discussed, as the use of this practice is about two decades old. Numerous articles discuss paired programming, its benefits (e.g., knowledge sharing), difficulties, and variations.

One of the results of this has been a significant decrease in defects. This is key towards the suggestion: for projects of greater complexity (starting at the upper range of medium), to better ensure project success, use a pair of project managers.

In addition to the need for compatible temperaments, the working environment needs to be supportive, with management not hostile to the idea.

During the initiation phase, having a 2nd knowledgeable viewpoint helps minimize likelihood of anything being overlooked in creation of a work breakdown structure (WBS); better communication planning; more inclusive and clearer risk identification and management strategies.

During project execution, .having two different people allows for more tailored stakeholder management, more bandwidth for individualized communication. In meetings, one can lead the meeting, with the other having the focus on analyzing the meeting dynamics, better able to avoid conflicts or facilitate their resolution if such arise, or even just taking better notes than one person trying to handle both.

If things start to really go badly, it is advantageous to have two perspectives, two sets of experiences upon which to draw, to turn the situation around.

Evaluate project complexity and success rates in your environment. If those rates are not satisfactory for projects of greater complexity, try paired project management.

Startups and Social Capital

At a recent evening meeting, a panel discussion under the #thinkleader program sponsored by IBM, the panelists represented different startups. They were smart, energetic and focused, aware of the murky waters in which they swam. It was clear that they had considered and planned for financial capital; likewise for the talents and skills needed. But a common thread of difficulties had to do with external support for their fledgling companies.

One panelist had been surprised at the drop-off from when he was a manager at a well-known brand, with many eager acquaintances, to the sudden vacuum now that he was co-founder of a startup. It wasn’t just the challenge itself posed by the need for external support, those willing to give referrals on their behalf, pass along useful ideas and the like, but the element of surprise of that drop-off.

Startups need to include building of social capital as part of their business plan. It’s not just marketing or branding. The ability to count on someone for information, for referrals, for the myriad types of support that can face a startup is a form of wealth. In a prior post, focused on individuals, the concept of Cognitive Wealth was explored. Similarly for startups, social capital needs to be planned for and built, as an explicit part of the business plan.

And if you’re young in your career or going through a major change, try thinking of yourself as a startup.

Innovation and the Octopus

To create something innovative, one needs to look at things in a new way, going a quantum leap away from the well-trodden paths of the usual. To help stimulate creativity, try examining something unusual, something very different from our familiar world view.

Our way of viewing the world is that of an upright two legged, with two upper limbs and a hand at the end of each, having prehensile fingers.

Our companion animals usually are 4-legged, mostly with more acute sensory abilities than us, but overall, not too unlike ourselves and our view.

Our robotic creations tend to follow those structures and patterns, remaining close to the familiar.
For a very different perspective, consider the octopus and their marvelous abilities; a species millions of years older than our own.

Invertebrate: a large octopus can still squeeze through a 2 inch opening (or even smaller), presenting a challenge to keeping curious octopuses inside man-made containers or tanks. To date our robotic designs are vertebrate-centric; one might consider a soft robot, modeled after the octopus.

While almost all our cognitive neural capacity is centrally located in our brain, the octopus uses a more distributed model, with only about half centrally located, with the rest distributed to its limbs.

A user of tools and toys, one might contemplate what an octopus considers amusing or beautiful. What are the means and media of beauty and harmony for an octopus? How might that intersect with our own aesthetic concepts? Does the geometric pleasure of a Bach fugue resonate for an octopus?

Octopuses exhibit a wide range of behavioral patterns, perhaps falling into categories: are some more extroverted? How can one design a Meyers-Briggs type personality test for an octopus? For robots, how does one differentiate an introvert versus extrovert?

One might not readily associate the octopus with fashion and design, but some creative ideas might arise from contemplation of how a color-blind creature superbly camouflages more quickly than a chameleon. Could a chair be adaptive to the color or pattern of clothes worn by the person adorning it? Or have jewels adapt to nearby attire? (e.g., a modernized, Tiffany-class mood ring).

So much difference from our own way of being, our perceptions, should lead to some inspirations for innovation.

For those curious about the wonders of the octopus, try Sy Montgomery’s “Soul of an Octopus”. It’s a rich, clear and easy read, with the author’s tinge of wonder about the world.

Increasing Cognitive Wealth

Your cognitive wealth is the sum of what you know, your personal knowledge, that which you are able to perceive; plus knowledge readily accessible whether from a search engine on the internet or from one’s personal library; plus information easily obtained from others.

The part based on one’s personal knowledge is the easiest to control and have immediate impact. Develop an approach to learning; think about the processes you perform when trying to learn something new. Your strategy for learning should include some way of becoming aware of new things that might be of interest, continuing to broaden your horizons. For me, reading is a preferred way of increasing my personal knowledge, supplemented with online video tutorials, and face-to-face group meetings, especially for subjects of professional interest.

The part that is readily accessible knowledge is a bit trickier. One is now relying upon tools (a book is a tool). One of the challenges is to find the right tool at the right time; a large personal library without some organization is of diminished value.

To increase the wealth brought by the internet, learn about the parameters of search engines. One needs to supplement the general search with a more focused one. Valuable nuggets are often buried far down when using a general search. For example, use of the “site:” modifier might yield information closer to the top of your search list. Another is to try other search engines, perhaps specialized ones.

For some topics augment your search engine by directly searching in Twitter. The jewels there might take the form of links to useful articles that might not show near the top of results from a general search engine.

Enriching the quality of one’s relationships with others increases the ease of obtaining information from them. You need to be aware of not just who might have knowledge on a topic, but also of their willingness to share with you, and the ease you have in communicating your need to them.

One means of improving that is to make your own knowledge readily available to others. Carrying this further, if I know someone well enough, I’ll keep my eyes open for information of likely interest to them. A form of social arbitrage, not only connecting people with others, but with information that they’d appreciate. That connecting and sharing enriches not only you, but those around you.

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 …..”

What’s Missing From Your SDLC

Having an SDLC (Software Development Life Cycle) documented is not to provide a minimum effort on development, or something to ignore, and keep writing programs as the mood strikes.  It’s part of an effort to follow best practices, to deliver high quality software on a repeated basis.  Even Agile methodologies can have an SDLC.

SDLC’s usually cover the core of the process of software creation, from initial requirements through design, coding, testing, integration, user acceptance, etc.  Some key elements are often overlooked, or considered not to be part of software development.  I’d like to suggest that you think about some areas that might improve the quality of the software you create if they are part of the SDLC.

Production support is not just about maintenance and fixing defects.  It’s about the ongoing improvement of what you delivered, preparation for the next release; part of the SDLC.  It’s about empowering the users, giving them the ability to fix their own problems when possible and reasonable; giving the right tools to the first level of support.  Not just documentation, an FAQ, or online Help, but items like creation of an error log and error trapping.  If the application has a database or data store, did you design a quality check on stored data, not just relying upon front end edit checking?

Does the application offer its users the opportunity to report problems, or give feedback about the interface they use?  What are the processes you envision for the ongoing improvement of the product?

Some SDLC’s include a Lessons Learned as part of closing out the development effort, project wrap-up.  The problem with that is it doesn’t do any good for the project in question, since that’s over, and seldom is examined either for the next release or by other projects.  Taking a page from the Agile approach of a retrospective for each iteration (sprint), why not do a Lessons Learned at each major milestone in the project, so the project can actually benefit while still in progress.

Security reviews should be part of the SDLC for all applications, not just web apps, not just for external facing ones.  How vulnerable is your application if another behind the firewall is compromised?  Security is part of the design process, not just something during the testing phase.

Security challenges are constantly changing, and some level of awareness needs to be part of the mindset of developers, not just IT security professionals.  Look towards organizations like OWASP (Open Web Application Security Project) as a resource.  Their Top Ten Security Risk list might startle some of your peers.

https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

The Department of Homeland Security has some excellent resources, such as a National Vulnerability Database http://nvd.nist.gov/  as well as checklists and guidelines.  Look around their site.

Security is often a nightmare for developers, but there are people, organizations and tools to help you.

Look at your SDLC, think of the ongoing life of your applications, and what might enhance their quality.  The SDLC is an ongoing opportunity for process improvement.