blog.thelemur.com » Processes

Taxonomy-Based Risk Identification

lemur — Sat, 15 Nov 2008 08:01:05 +0000

Identifying risks associated with software development is vital for project success. In most cases, developers are aware of risks throughout development but potential problems are not communicated in a way that reflects uncertainty in project health.

Taxonomy-based risk identification is a loosely structured method for quantifying risks during the planning phase(s) of software development.

Process

A project manager interviews developers using a questionnaire to identify risks in different project areas. These areas are referred to as “classes”.

Advantages for Adopting this Method

Risks are identified earlier in the project
Formal procedures exist for risk identification which helps reduce the ad-hoc nature of typical risk identification in software projects

Dangers of Adopting this Method

Inexperienced or untrained developers will not be able to identify risks properly
Uptraining may take time away from critical project activities
Inexperienced teams usually lack defined risk management procedures

References

http://www.sei.cmu.edu/pub/documents/93.reports/pdf/tr06.93.pdf

This PDF contains the TBRI abstract and the following topics:

Background and motivation for introducing a taxonomy-based approach
Results of studies which were used to refine TBRI
Sample approaches for introducing TBRI into your company and project routines
Sample interview questionnaires

Using Wikis for Project Management

lemur — Wed, 06 Aug 2008 20:36:06 +0000

Among the extravagant web-based project management solutions on the web (Basecamp, @task, Wrike, VeoProject, Clarizen, FogBugz, …more) lies an overlooked gem called “Wiki.” A Wiki is a website designed for collaboration. Wikis allow multiple authors to create, remove, and modify content. The inherent collaborative nature of Wikis makes it a perfect addition to the project manager’s arsenal. Wikis cannot replace software written specifically for PPM, but Wikis can assist organizations during development. This article reviews the following:

Some of the relevant features and uses of Wikis for PPM
Some overuses of Wikis
Possible risks associated with using Wikis
A list of articles that prompted me to try Wikis for PPM

Wiki Features

Wikis are built for collaboration.
Wikis implement unobtrusive document versioning methods.
Category and page structure is flexible but can be standardized for specific needs.
Wiki content is stored as plain text. This makes it easy to duplicate and format in a text editor if necessary.
Plugins and extensions allow further customizations to suit your organization’s needs.
Relatively easy to maintain. (Most of the Wikis I tried had simple install scripts)

Recommended Uses of Wikis

Meeting and phone conversation notes
Requirements gathering
Planning project design
Risk analysis notes
Writing user stories
Lightweight asset management (documentation, comps, UML diagrams)

Overuses of Wikis

It’s probably best to use a separate tool for the following project tasks:

Bug tracking
Time tracking
Code versioning
Code documentation

Choosing the Right Wiki

If you have not already selected a Wiki package, I recommend reviewing these links:

After you have selected and installed the Wiki of your choosing, it is time to move on to structuring and securing content.

I chose MediaWiki because of its simple installation process and configuration through LocalSettings.php. A friend of mine brought up a good point – most people will be familiar with MediaWiki because Wikipedia uses it; everyone has visited Wikipedia.org.

Wiki Categories

Determine what topics you would like to store in the Wiki and how it will be organized before adding content. This planning will prevent dead links and reworking the Wiki’s structure. Refer to MediaWiki’s category help page for more information and recommendations.

Wiki ACLs

By default, wikis are not built to enforce strict access to pages, categories, and media. Custom extensions can provide Access Control List (ACL) behavior. I would adopt an ACL extension only after considering the sensitivity of your Wiki content. This list contains potential MediaWiki vulnerabilities for adopting 3rd party ACL extensions but may also apply to your wiki software. If you use a MediaWiki alternative, see if it has a built-in ACL or documentation regarding the risks of using ACL plugins.

I recommend installing a new Wiki for each client and protecting the directory with an .htaccess file in favor of using a 3rd party ACL.

Wikis and Version Control

Storing Wiki contents outside of development repositories creates a divergence between project plans and project code since Wikis have their own version control mechanism. This divergence does not introduce risk if the latest project plan is always relevant regardless of the code’s stability. I would recommend keeping Wiki content and code separate because duplicate version controls on a project asset is dangerous.

References

Kelly, William. “Building a project Web site the easy way.” TechRepublic – A Resource for IT Professionals. 12 Mar 2003. Tech Republic. 6 Aug 2008 <link>.
Macomber, Hal. “Proposal for a P-Log Specification.” Reforming Project Management. 2003. 6 Aug 2008 <link>.
Adamy, Miro. “Project management using Wiki.” Miro’s World. 05 Mar 2007. 5 Aug 2008 <link>.
Child, Tim. “Wiki as project management tool..” blog.timc3.com. 19 Nov 2006. 6 Aug 2008 <link>.
Hohman, Jamie. “Wiki Customization to Resolve Management Issues in Distributed Software Projects.” Software Technology Support Center. Aug 2008. STSC. 6 Aug 2008 <link>.

Friday Wrapup Meetings

lemur — Sat, 12 Jul 2008 21:21:19 +0000

Every Friday, developers and managers should meet briefly to discuss the successes of the previous week. A Friday Wrapup Meeting should include all team members regardless of their status, position, or present work-load. The meeting’s mood should be kept upbeat and the discussion should be used to highlight company successes and developer contributions over the past week. This article contains recommendations for conducting these meetings.

Stay Positive

As a general rule of thumb you should avoid negative discussion topics. I should mention this has little to do with sugar coating a slacking developer or ignoring potential problems. Conflicts should be identified and resolved but Friday Meetings are not a suitable environment for this process.

The Friday Wrapup Meeting is conducted at the end of the day on Friday, which gives developers about five minutes after the meeting before they head home for the weekend. If a developer receives schedule pressure for delivering a product, they must wait until Monday to resolve the problem. Negative feedback during Friday Meetings is counter-productive because there is no way for the developer to immediately resolve conflicts without losing time in their personal life. Developers should be encouraged to enjoy their weekend, not stress over work.

Recommended Discussion Items

New tools, software packages, and development suites that were reviewed or added to the company’s tool arsenal
Creative or innovative solutions to problems encountered during the week
Company-related successes such as new projects, clients, or employees
Improvements to development procedures
How an employee’s work improved or benefited the company

Discussion Items to Avoid

Updates on project estimates
Reminding developers about upcoming deadlines
Problems encountered during the week that still pose a threat to project health
Company-related pitfalls
Nagging developers to finish work; public humiliation is rarely effective

The Project Manager’s Role

The project manager’s role during Friday Wrapup Meetings is to analyze and transcribe individual developer motivations. Listening to the things that excite your developers reveals potential motivation techniques.

Examples of Interpreting Motivations

A non-JavaScript programmer creates a JavaScript widget: take screenshots of the widget in action and give the programmer a print-out of the widget to put on the wall.
A programmer develops a framework or complex system: have the developer create a class diagram of the framework and frame it above the programmer’s desk.
A designer creates an amazing website design: have the designer piece together a montage of the wireframes, sketches, conceptual pieces, and the final product. Have the designer post this on a wall for everyone to see.

Public Displays of Success

From my examples above you can see I’m leaning towards displaying things developers have worked on in the past. Displaying income earned over the past month or a screenshot of an entire website is a good start but it doesn’t highlight individual contributions. Remember that managers and developers have fundamentally different motivations. Managers are traditionally focused on success while developers are more focused on learning and personal growth.

Side-Effects

Side-effects may include but are not limited to:

A company atmosphere that encourages personal growth and exploration
Developers are reassured their managers are interested in what they have to say
Developers are more motivated because they feel appreciated
Increased team cohesion, which is provided by team members listening to others

References

McConnell, Steve. Rapid Development: Taming Wild Software Schedules. Redmond, WA: Microsoft Press, 1996.

McConnell, Steve. Professional Software Development. Boston, MA: Addison Wesley, 2004.