My views on Software Project Management

iCloud = Cha-ching!!!

On a completely different subject, I wanted to express some thoughts about the recent Apple, iCloud announcement. For Apple’s future turnover, iCloud is quite simply a fantastic idea!

The commercial advantages of giving away 5GBs of free and automatic online storage are threefold:

1. Obviously, iPhones and iPads have an advantage over other devices currently on the market.
2. The longer you possess an iPhone and/or iPad, the more you will be locked into using future Mac products. The day you want to replace your iDevice, you will certainly not want to lose your photos, music, emails, books, games, …
3. By synchronizing between all your iDevices and Macs, it will lure future consumers to opt for Apple-only products. In other words, if you already own an iPhone and you need to replace your notebook, you are probably going to purchase a Mac book in order to take advantage of the synchronization. You will never have to run iTunes to synchronize your iPhone on Windows every again!

The online storage advantage will be temporary as other vendors will have to hastily follow. However, I doubt the competition will be successful because they will lose out on points 2 and 3.

Drop me an email (grant.barry@gmail.com) or tweet (@grantbarry) and tell me what you think!

Insufficient planning?

Project planning is vital to a project’s success however it is always a challenge to spend enough time planning. Project planning is often put aside in order to get on with the work.

The true value of project planning is often unseen so as a project manager, team member or customer, you should promote planning at every opportunity. Project planning will save time, increase deliverable quality, reduce problems and help ensure a realistic project schedule.

What are the signs of insufficient planning?

• Impossible deadlines
• Incorrect or no progress visibility
• Rework due to unclear requirements
• No time allocated for quality & testing

Here are some principles of project planning that will help:

1. Create a project vision
List the project objectives (goals) and establish a project vision statement (a one-liner which describes the project). The project vision statement should be used in all your emails & project documents.
Developing and maintaining project vision will help manage deadlines and avoid rework.

2. List project deliverables
Take time with your team listing project deliverables. This will help outline all the work that is needed. Without this step, you are sure to find yourself knee-deep in work that was not identified at the start of the project or phase.
Listing project deliverables will help manage deadlines, progress visibility, manage requirements, avoid rework and help plan for quality.

3.  Develop a project schedule
With your team, develop a project schedule together. A project schedule should take into account the known work/project deliverables, holiday periods as well as additional time for re-planning, rework and changes.
Schedules also serve to commit team members to the project.
Regardless of the methodology you are using to manage your project, a project schedule should be divided into manageable phases. Each phase should provide some sort of deliverable (functional specifications, prototype or simulator, test version, etc.). Within the project, I personally suggest dividing into 5 phases (planning, designing, developing, testing and finalizing).
A project schedule is not just a Microsoft Project file that was created by the PM and is only used by the PM. A project schedule must be usable by all stakeholders.
Project schedules will help manage deadlines, progress visibility, manage requirements and allocate time for quality.

4. Monitor progress
Depending on the size of the project, you may want to monitor day-by-day tasks or have monthly progress reviews. In any of these cases, it must be done.
Scrum burn down charts or Earned Value Management (EVM) charts should suffice for most projects.
Monitoring project progress helps manage deadlines and project visibility.

The importance of gathering requirements

Before writing about requirements, I want to explain what I mean by requirement. A requirement is a necessity or prerequisite that is asked by a stakeholder.

I say stakeholder and not customer because requirements can come from anyone, not only the customer.

Project Managers will always be faced with stakeholders who cannot tell you exactly what they need. Either stakeholders simply do not have a clear idea or they cannot effectively communicate their needs. Whatever the case, it is up to you as the project manager to help define a clear and precise set of product and project requirements.

The benefits of defining requirements are evident:

1. Avoid rework
2. Helps set stakeholder and project team expectations
3. Improves quality and ultimately saves time in all project phases (planning, design, development, testing & delivery)

Before gathering requirements, ask yourself the following questions:

1. Have all project stakeholders been identified?
2. What information or previous experience can be brought to light?
3. Do I as a project manager, have the processes and tools in place to document, communicate and manage requirements?
4. How will changes be managed?

Don’t leave anything to chance! Gather the maximum amount of detail for each requirement. The information and detail will serve later on in your project.

Take the following example: During the formal requirements review meeting you organized, a stakeholder asks to support the following languages:

• English
• French
• Spanish

You’ve probably already read several specification documents and have seen a similar list.

Take a minute to break up this requirement and get clear responses from the stakeholder:

• What language must be displayed on an operating system with a different language (German, for example)?
• English can be broken in English - United States (en-us), English - Canada (en-ca), English - Great Britain (en-gb), … Should we localize and default to English - United States or does the stakeholder want to support all flavors of English?
• Again, French can be broken into different countries.
• Spanish can be a little more trickier since you cannot simply default to one flavor of Spanish. Catalan (ca-es) is very different to Spanish - Mexico (es-mx)

My take is to list all major languages in a table of supported languages. The table columns being

• Locale - The language name, English - Canada for example.
• Short String - The locale short name, en-ca for example.
  
• Locale ID (Hex) - The locale ID or LCID (Win32), 0x1009 for example.
• Locale ID (Decimal) - The locale ID or LCID in Decimal, 4105 for example.
• UI Language - The language which must be displayed, which can be different for the language. In our example, English - United States must be displayed.

Below the table, add a clear sentence explaining that English - United States will be displayed in all other cases.

This will make it clear for stakeholders, developers and testers.

At all stages of the project, the customer, developers and testers will know what languages are supported, what language will be displayed on-screen and no nasty surprises should arise.

If you need more in-depth information in requirements management, I suggest reading up on the following CMMI process areas:

• REQM - Requirements Management (Level 2)
• RD - Requirements Development (Level 3)

Reporting bugs

Any of you who have ever managed a project or developed an application has at some point, come across a useless bug report. “It didn’t work right” or “See the screenshot” to which a screenshot was never attached. This is not only a waste of time but it also frustrating for any quality-orientated team member.

Apparently, there is a bug but time is going to be wasted tracking down the necessary information.

So how can a Project Manager put a stop to useless bug reports. Well, my take has been a simple process called REDSOX. Yes, as in the Boston Red Sox. Anyone who wants to report a bug, needs only to remember REDSOX. Let me explain. When you write up your bug report, start by writing R E D S O X. Now go back and fill in the information like this:

R stands for Results. In other words, describe in a sentence or two what was seen or experienced.

E stands for Expected results. This is important as it describes what the expected functionality should be.

D stands for Data. Report on the settings used, the version of the software and executables and attach Screenshots, log files and any other files which may be handy.

S stands for Steps to reproduce. This will help developers and testers understand and verify the fix. In some cases, the bug may need to be reproduced by the developer in order to gather more detailed information.

O stands for Operating system and hardware information. Report the exact edition of the OS, the service pack(s), the software and services which are running and generate (or report) as much hardware information as possible.

X stands for X-check. This means that before submitting the bug, read your report. Make sure you have noted the facts. Leave out subjective information. Check that all the information is correct.

With REDSOX, you should see a dramatic improvement in the quality of the bug reports.

Feel free to reward team members which actual Boston Red Sox items like pins, t-shirts and caps. You can also remind team members who are not respecting the process in the same way.

Feel free to send me a message and tell me how REDSOX helped you.