Project Management for Programmers

Did you know 70% of all software projects fail or never reach completion?

In addition to project managers, software developers should also know this because the project manager may not and in some companies there are no project managers.

Why am I qualified to talk about this? I worked at two big software companies then later I ran the Programming Labs software company for 15 years, and after that I was CTO for 5 years. Programming Labs was my software development company. We had several clients and I successfully managed all their projects from small enhancements to enterprise-level multi-year projects.

This information is also available in this video:

Roles in a Project

Stake Holders
Software Developer(s)
Project Manager

The Project Manager acts as a liaison between Stake Holders and Programmers.

Project Management Statistics

The average salary for project managers is $89,500 in the U.S.
70% of projects fail!
57% of those fail due to breakdown in communications.
Three-quarters of projects fail because senior management doesn’t get involved.
The failure of IT projects costs the U.S. economy about $50-$150 billion annually.
The failure rate of projects with budgets over $1M is 50 percent higher than the failure rate of projects with budgets below $350,000.
75% of respondents lack confidence in project success. Fuzzy business objectives, out-of-sync stakeholders, and excessive rework are key culprits.
The average cost overrun was 27%, but one in six projects had a cost overrun of 200% on average and a schedule overrun of almost 70%.
55% of project managers cite budget overrun as a reason for project failure.
17% of IT projects go so badly, they threaten the existence of the company.
Stakeholder engagement is the most valuable PM process.
42% of companies don’t understand the need or importance of project management.
Organizations that undervalue project management see 50% more of their projects failing.

The links are below in the description for sources on all these statistics.

Quantifying Project Success

From the statistics you can see most projects fail and the main reasons are communication related.

Poorly defined specifications.
Poorly defined goals.
Bad estimates for cost and timelines.

If you follow the guidelines in this video you will have these primary issues covered. It won't insure your success, but it will increase your odds dramatically.

It is often joked that a Project Manager is a person who believes that 9 women can deliver a baby in one month. This is because of the typical pressure by Stake Holders to get projects done faster by throwing more resources at it. Your job as a PM is to bring them back to reality.

There are a ton of obstacles for any project that may make them fail. You don't want the project to "fail" because of something basic like Stake Holders disagreeing on what the final result should be. When you are finished with the project you want to be able to deliver to all Stake Holders and your manager a document showing all the (adjusted) timelines were met, and every feature and functionality was delivered.

There should be clear-cut division of duties and responsibilities. Some Stake Holders will assume the project is not complete until it has been beta tested in three states, marketed internationally, and television ads have been aired on the Super Bowl. As Project Manager you need to set proper expectations. If the company has a Quality Assurance Testing department which you do not control, that should be noted in the timelines. The "Phase 1" of the project should end as soon as possible with a clear definition. For example, the project is complete when mobile app is on both the Apple AppStore and the Google Playstore. Not when there has been 1,000 downloads.

Cancel before Begin

Should you cancel the project before you even begin?
Clients will often give a rough outline of a project and think that is good enough. In most cases they are not thinking it through completely.

For example, let's say a client asks for a shortened URL redirector. This sounds like an easy project at first glance. And it can be if they don't need any bells and whistles.

As the project manager your first action should be to review whether there are third-party completed solutions that meet the client's needs. This will also give you a lot of ideas on what features you should be considering for your design. Then the first question to the Stake Holder should be "Why do you want us to custom build this from scratch instead of using a third party service?"

As the PM you are not trying to talk them out of doing the project. But you do want them to realize the alternative options and the cost in time and money for their decisions. If you can save them a huge amount of time and money they will consider it a "win" and usually come up with new projects very quickly. If they know the alternative options and yet still choose to go forward with the project, they are already increasing the budget in their minds.

Outline Reports First

As Project Manager your job is to help Stake Holders write a complete Functional.

One of the ways to do that is by asking what analytic reports will they want after the project is done. Defining the analytic reports will cause many discussions amongst the Stake Holders and most of the time the Functional specifications are very different after this step.

By having the reports defined, this helps the software developers determine which database tables are going to be affected by the needs of the project. And what data needs to be tracked. Plus whether new data tables need to be created.

So you ask, "I assume you will want to track the number of redirects from your shortened URL. How do you want these tracked? Please send me sample reports of the analytics you want tracked." Then depending on the technical savviness of the stake holder, you will probably need to outline a couple recommended reports and then ask them to modify them and add to them. Just outlining a single report will lead to several discoveries and help the Stake Holders decide on terminology they want to use. For example:

Looking at the above report should open up a huge discussion for the Stake Holders. First it makes some critical assumptions that were not in the original specifications. Each shortened URL will get a "Link Name" so they make more sense in analytic reports. Date needs to be tracked for when URL is created. Number of clicks needs to be tracked as well as where these clicks originated.

It does not show the breakdown for Tablets. Do the Stake Holders want the report to say "iOS" or "Apple"? It shows iOS and Android but not Windows mobile phones. For the OS breakdown, does the 44% for iOS represent only phones, phones and tablets, or is it mislabeled and really is supposed to represent all things Apple including desktops/laptops? Or are none of these analytic points important?

Do they want a report built showing the referral pages that called each link? Do they want this to be a summary report for all the shortened URLs, or be specific for a single shortened URL? Most likely they want both. Do they want a graph report showing number of clicks per day in a date range; should that be a line graph or bar chart?

Asking these questions and forcing the Stake Holders to outline all reports before the project starts really helps them define their goals. It also greatly helps them realize their "little project" is actually going to be a lot of work.

Making them decide at the beginning will determine whether the project is considered a success or failure at the end.

What is a Functional Specification?

A functional outlines the project from the client or Stake Holder's point of view. It should not use overly-technical lingo. What are the goals? Are there any deadlines that must be met due to upcoming events? For example, must be completed before XYZ convention so can be presented there. What requirements need to be met to consider project completed and a success?

The functional needs to be completed with the analytic reports defined before the technical or any timelines are given.

What is a Technical Specification?

Once the functional has been signed-off by Stake Holders (and never before), then the Technical needs to be written. The Technical Specification document is also known as Software Design Document (SDD), or Software Design Specification (SDS). This explains how a specific piece of software or software feature should be developed. They're important technical documents that focus on the how of the development process.

Sometimes this is written by the Project Manager but more often it is done by a Software Engineer. They take the Functional and review it carefully then write the Technical document outlining exactly how the functional goals will be attained.

The five goals of the Technical:

Verify that all aspects of functional are technically possible given the company's database/technology/services.
Catch any aspects of the Functional that greatly increase time to develop and offer alternatives.
Based on greater understanding of the technology, briefly outline any major new features or functionality that could be added for either minimal effort or massive cool-factor/profitability factor.
Write high-level outline how each functional aspect will be completed. This later will be sent to developers to do the coding.
Figure out rough timelines to complete each section in the Functional

This does not involve any code writing. This is just outlining which database tables will be accessed, which new data tables need to be created, what APIs will be used, and everything technical to accomplish the functional goals. This does contain technical lingo and most likely Stake Holders will not see nor understand this document. The Project Manager should though and from discoveries during the writing of the Technical they may need to alter the Functional or bring the Stake Holders news about high-level decisions they need to make.

For example, "During the writing of the technical it was discovered that in order to make deep linking work we will need to make major changes to both the iOS and Android apps. This will be a huge secondary project because Apple and Google have made changes which will require Viewport code changes. We recommend postponing the deep linking until phase two so the rest of the project can be deployed as soon as possible. Otherwise we will need another week just to analyze how long this will take and it will likely add months to the completion of the project."

Note: the above is far better than spending the extra week writing the technical to include revamping the mobile apps. Ask Stake Holders if they even want that analysis done.

Approve, Review, Approve Again, Repeat

So after the Functional is written it needs to be signed-off by the primary Stake Holder.

Then the software engineer writes the Technical Specification. This should include rough time lines including when the entire project should be completed and any recommendations on changes to the Functional.

Project Manager delivers recommendations and timelines to Stake Holders (but usually does not deliver Technical since they would not understand it). PM works with Stake Holders to adjust and modify Functional if necessary. Then Project Manager gets all Stake Holders to sign-off on the updated Functional.

Sometimes the Stake Holders change specifications after seeing the recommendations and time lines from the Technical. They may decide to cut entire features. If so, the PM needs to ask the critical question "Will there ever be a time where we will need to add that feature later? If not then the Technical may be able to remove associated related data tables and internal processes."

At this point it is common to break a project into a Phase 1, 2 and possibly a Phase 3.

If anything in the Functional changed, the software engineer needs to review all changes and update the Technical. Even a seemingly minor change by Stake Holders can have HUGE impacts. For example the Stake Holders may say at the last minute, we love the Functional and Technical for the mobile app. We only made one minor change, it needs to work on MS Edge instead. No biggie, right?

Estimating Timelines

This will have to be a topic for another video. The short answer is estimate in days, not hours. Then increase for the unexpected. Let everyone know these are "rough estimates only". Then add the caveat that if there are any changes at all the time estimate needs to be re-evaluated.

Also mention that changes are expected, thus the timeline should be updated with every iteration. During development you should be giving prototypes and sample screen shots and asking questions weekly. These will often lead to minor or major changes. That's Agile Development. Then you adjust the Functional, the Technical and the timeline and move-on.

As a project manager when you talk with Stake Holders they are always going to ask for more, faster and cheaper. You have to remember the golden rule.

You can have it Quality and Fast but it won't be Cheap. Or you could have it Fast and Cheap, but it won't be Quality (aka, expect lots of bugs and not to work on all devices). If you want it Quality and Cheap, we will work on it but all other projects get higher priority and this may take a long while to complete. Most clients / Stake Holders will choose Quality and Fast and thereby acknowledge it won't be cheap.

Summary

Extremely organized companies that take project management seriously have a project success and completion rate of 89%. Unfortunately that is rare. The majority of businesses have a 30% success rate and it's mostly because they do not follow any procedures. I have uploaded the Functional, Technical and this article to my Programming Labs server. The link to download is: