White paper: Implementing an Enterprise-wide Issue Management Platform

An enterprise-wide issue management platform should typically facilitate capture and tracking of defects, tasks, quality checks, support tickets, change and feature requests from multiple locations, departments and even multiple organizations.

Implementing an issue management platform goes well beyond the traditional Software Development team. Clients, vendors and other organizational departments also require project participation. During the implementation many organizations seek guidance around project structures, user access rights, metadata, and workflows. The rationale is that investing some time upfront to structure the implementation saves the “refactoring pain” that typically follows once the issue management  platform is in active use.

Problems are usually compounded when multiple applications and project repositories are deployed thus resulting in “multiple versions of the truth”. A single issue management platform for all users will yield a “single version of the truth” – no room for confusion is left if all users adopt the same project platform.

We could summarise the necessary steps as follows:

• Understand potential users, project types and the relationship between projects – “are we managing both Support and Development projects?”
• Identify business processes to be managed – “are we tracking Defects and Change Requests?”
• Determine data requirements for different business processes – “what data fields does the user fill in when logging Defects, and when raising Change Requests?”
• Plan for external participants requiring project participation – “which external entities need access to the platform to view, update and close tasks?”
• Adopt readily understood and consistent terminology – “should the platform state “Modules” or “Components” when describing elements of the application in question?”
• Design and implement now, tune later – “focus on rolling out the platform and optimize it later for additional benefits.”

No related posts.

We have started off by open sourcing the Gemini Snagit screen capture integration:

http://gemini.codeplex.com

Also introduced is the Greenshot screen capture integration with Gemini:

http://geminigreenshot.codeplex.com

You can read more on Greenshot here: http://greenshot.sourceforge.net

For all such projects complimentary issue tracking will be provided at http://opensource.countersoft.net

Gemini Community Codeplex Homepage: http://gemini.codeplex.com

Codeplex Open Source Issue Tracking:  http://opensource.countersoft.net

No related posts.

They huddle in a corner, hunched over the Gantt chart you just handed out, muttering darkly.  Only the occasional, quick glance in your direction betrays that you are the subject of their reproach.  You sigh and for a moment are tempted to bat for your corner, but in the end you realise that it’s best to ignore them.  A quick drink after work and they’ll come round.  Instead, you scan through the list of Change Requests, Outstanding Issues, Bug Fixes and the Financial Summary and prepare yourself for your next meeting.  This one ought not to be so bad, the Client might not like what you have to say either but at least they don’t see you as the enemy within.

Who would be a Project Manager?  There are times when it is akin to being a referee at a particularly fractious soccer match.  You have to keep both sides apart while making sure that they play the same game and abide by the rules that they want to wilfully ignore.  Sometimes it feels as if only you realise the fundamental difference; this is not a game, and if one side loses then nobody wins!

The classic portrayal of the gap between requirements and delivery.

We’ve all seen the cartoon about the difference between what the Customer wanted and what they got and we all know who has to manage the gap. What the team on both sides of the requirements/delivery divide should acknowledge is that this situation does not exist only as a comic creation, it exists as inevitable outcome of the fact that requirements evolve from abstract needs but Software Developers can only build still life.  If this was honestly stated by all parties right from the outset then the first question that would be asked is who is going to make sure that we all walk away from this with a satisfactory outcome in the bag?  The notion of the Project Manager as the Client’s mole or the Supplier’s secret salesperson would evaporate.

One of the most irritating debates would also get put to bed; namely why the Client should pay for Project Management.  The client should pay because the Project Manager serves the project, not the Client nor his or her direct employer, who only employs Project Managers because they have long experience and understand the necessity of Project Management.  A Project Manager is a necessary part of the cost of delivery.

Fortunately we live in a world where the value of a good Project Manager can be proved beyond doubt, provided he or she tracks everything related to the “infamous gap“; issues, changing requirements, moving time lines etc., and stays on top of it.  Our Project Manager can walk into a meeting with the Client or Delivery Team, and the data at their command rams home their value to either side.  Wait a minute, either side?  Maybe Project Managers are the enemy within after all.

No related posts.

The issue is one of risk and who takes it. With a fixed price project the risk is deemed to be the supplier’s, with T&M it is the customer who takes the risk. This ‘risk’ is presumed to be the risk of overrun, in other words if the project is not completed on time the cost of resources to continue working on it will be borne by one party or the other.

In the fixed price scenario, the supplier is in theory happy to accept the risk because it is the supplier who names the price and sets the timeline. If the project comes in early then the supplier makes a super profit because the engagement was profitable even if it was only on time and the supplier is usually allowed to add a mark-up to the project for accepting fixed price risk in the first place.  Everybody is happy unless the project comes in so late that it eats into the supplier’s contingency and extra margin, but if that should happen it is the supplier’s fault anyway for getting it so wrong in the first place. Or is it?

In reality the supplier rarely sets the price or the timeline. Customers don’t just sit back and accept the estimates they are given, they negotiate and they usually negotiate the fixed price risk factor away. Suppliers need the business and recognise that if they don’t do it their competitors will, so they take the risk of a fixed price project scoped out to meet exact deadlines. However, if they fail to meet those deadlines they do not passively accept the cost of the overrun either. Even if it is entirely their fault, suppliers will do their utmost to stay in business and running unprofitable projects is not a good way to remain solvent. They will under-deliver on what was promised, scale back on resources allocated to the project, either by using less or cheaper labour, and they will hit back with that dreaded weapon, the Change Request. When the arguments start over the Change Requests then nobody wins.

If we look at what was intended rather than the means of getting and paying for it we might be able to see a way out of the problem. Customers want good, reliable software that addresses a need that they have. However suppliers cannot give customers what they want; they can only give them what they ask for.  Customers, not being experts in the software development business frequently don’t know how to ask for what they want. Sometimes they do not even know if it is possible to get it. If you know that there is a gap between what the customer asks for and what they want, and you have enough experience to know that they rarely like what they are given first time, then the solution is to show them what they are going to get, early.

Project Managers should try to minimize the size of the gap by making sure that as far as possible the customer sees what they are going to get as soon as possible, in small chunks. The sooner the “what you want” vs “what you get” battle is fought, the sooner the “risk” vs “pricing” issue gets resolved and the more likely the project is to succeed.

We call this “Minding the Gap” and we learnt to do this because the reality in large projects is that there is rarely only one gap. The need to “Manage the Gap” is just as great as the need to recognise it in the first place. Even Agile / SCRUM projects can fail if you fail to properly “Manage the Gap”.

Every issue represents a potential chasm for funds and resources to pour into and that is why Issue Tracking tools like Gemini can be extremely beneficial to all parties concerned.

No related posts.

Typical questions, but now visually answered with our new-look Road Map and Change Log.  For each Project Version, a handy summary is provided in both Road Maps and Change Logs:

Version Summary

But it gets better when you typically have lots of Project Versions.  See how you can quickly get a feel for each Version’s content type as Gemini shows you the Top 3 Issue Types per Version:

Version Headers: Quick Summary Information

Now users can quickly understand what kind of issues were predominently address per Version.

We think this is a step int the right direction, given the amount of information we all now have to take in regularly!

No related posts.

So what would help you?

For starters, a quick tabular summary week-on-week, broken down by issues Created, Closed, and Commented would help.

A handle on Project activity since you last logged in would also be handy.

Project Metrics

This kind of instant visibility into Project activity is really useful when multiple Projects require your attention.

Useful: See Metrics for Multiple Projects

But how about some Charts across all Projects providing quick insights and week-on-week trends?

All Projects: Summary Charts

Naturally, the Charts are clickable — click through to see the actual issues behind the numbers.

See the Issues behind the numbers

Feedback and suggestions always welcome.  Note: this Post applies to Gemini 3.6 — check it out over @ http://beta.countersoft.com !

No related posts.

A common requirement is to configure Gemini to work with your SMTP server.  Then the fun begins: you have configured Gemini and SMTP but no email alerts are received.

So what can help you quickly debug the SMTP issue without having to change any of the SMTP server settings?

Enter “smtp4dev” — an Open Source tool that is available @ CodePlex (http://smtp4dev.codeplex.com).  It simply listens for SMTP traffic and displays whatever is sent.  It doesn’t actually send the email which makes it great for debugging and testing scenarios.

Here’s how to setup Gemini and use smtp4dev…

1. Install smtp4dev on the same machine that is running Gemini.

2. Use the following SMTP configuration (the important point is the smtp4dev listens on Port 25 but can be configured to use a different port).

Configure Gemini SMTP

3. Finally start smtp4dev and update an issue (or any other activity) that will cause Gemini to generate an email alert.  You should be able to view Gemini email alerts as follows:

Easily View Gemini Email Activity

Simple!

You will notice that if you click on a email message in smtp4dev it is in .eml format. You could also install Mozilla Thunderbird email client which will happily show the actual message as it would be viewed.  Alternatively, click on View Source and see the raw message text.

No related posts.