Articles

Looking for free, concise advice on a specific project management topic? You've come to the right place!

November 2005

How Much Is Too Much (November 28, 2005)
In a previous article, I describe why Project Managers should never excessively try to compress a project schedule. What I failed to do however is define the term "excessive". As a Project Manager, how can you determine if your schedule is aggressive yet realistic, and at what point does it become overly optimistic? How much is too much?

DeMarco, Lister and Parkinson (November 21, 2005)
In chapter 5 of their best-seller "PeopleWare: Productive Projects and Teams", DeMarco and Lister conclude that "programmers seem to be a bit more productive when they can do the (feature) estimate themselves, compared to cases in which the manager does it without consulting them." Backed up by scientific data, they construe that "projects on which the boss applied no schedule pressure whatsoever had the highest productivity of all." If the above statements were true, wouldn't it be best to "protect" the development team from project managers? Wouldn't the techies be better off left alone?

Excessive Schedule Pressure (November 7, 2005)
Schedule pressure appears to be endemic to software development. Many managers and customers defend their pressure tactics by referring to Parkinson's Law, which states that work expands to fill the time available . "Give a developer 4 weeks to complete a task and he'll deliver in 4 weeks, but give him 3 and he'll deliver in 3." If Project Managers can force developers to deliver software 25% faster, shouldn't we always apply schedule pressure? Shouldn't this strategy be considered a best practice?

October 2005

Five Simple Strategies for Unifying Project Teams (October 31, 2005)
Do your project team members show confusion about who is responsible for what aspects of the job? Do their conversations and meetings usually end in heated personal attacks? Or do individual members ever exhibit an "every person for themselves" attitude and refuse to help their teammates? If you answered "yes" to any of these questions, then you're not alone. Sometimes, a team simply doesn't "gel."

Disaster Recovery (October 24, 2005)
Natural disasters such as Hurricane Katrina remind us that disaster, whether natural or man-made, can hit anywhere, anytime. When such an unforeseen event results in loss of critical business data, recovery from the incident requires up-to-date backups and proven restoration methods. The following guidelines summarize how to develop a complete and recoverable backup environment.

Slack Attack (October 17, 2005)
Project Managers rely on various risk management techniques in order to identify, address, and eliminate sources of risk before they become threats to the successful completion of software projects. However, many of the so-called best practices used by Project Managers nowadays don’t “prevent” schedules from slipping. They simply allow Project Managers to identify slips earlier and consequently readjust their schedule. Can Project Managers really prevent schedules from slipping? Can we develop a plan that can actually account for inevitable minor setbacks that all of us face in our day-to-day chores?

September 2005

Continuous Improvement – From Theory To Reality (September 26, 2005)
Reality is no two projects are alike. And while you might, in retrospect, identify things that you could have done better in your previous project, it doesn't necessarily mean that applying your findings to your next project will automatically result in faster, cheaper, better software.

The Peter Principle (September 19, 2005)
The Peter Principle was first introduced by Canadian sociologist Laurence Johnston Peter in a humoristic book describing the pitfalls of bureaucratic organizations. The original principle states that "in a hierarchically structured administration, people tend to be promoted up to their level of incompetence" . The principle is based on the observation that in such an organization new employees typically start in the lower ranks, but when they prove to be competent in the task to which they are assigned, they get promoted to a higher rank.

Is Your Project Profitable? (September 12, 2005)
Your company just signed a $200K deal and they've elected you, its best Project Manager, to manage the development. You're confident you'll get the job done on time and according to specs. But by the time you deliver this project, how much profit will you realize?

The High Cost of Employee Turnover Among Project Managers (September 5, 2005)
Imagine for a moment this scenario from a frustrated Senior Manager: “Our organization has experienced a large turnover among project managers in the past year. This creates problems providing ongoing quality and service to our stakeholders. We just don't know what is causing the problem!” Sound familiar? Well you're not alone. I remember that filmmaker Woody Allen once said that “80% of success is showing up.” However, the greater challenge is finding ways to keep people there.

July 2005

Why Java RDBMS? (July 18, 2005)
It is a well known fact that Java as a programming language set off a new paradigm in the software industry. Suddenly, every software programmer worth his salt was amidst software jargons like 'Platform-Independence', 'Cross-Platform-Deployment' and ‘The Java Virtual Machine'. But what are the advantages of a Java RDBMS?

Software’s Best Kept Secret: "ilities" (July 11, 2005)
Many developers make the mistake of thinking that quality attributes, commonly referred to as nonfunctional requirements, technical requirements or ilities, are somewhat superfluous. Convinced that these nonfunctional requirements are not as critical to the end product as functional requirements, ilities are rarely documented or even understood. While quality attributes seem rather unnecessary to many developers, the fact is that they are critical to your product – and your business!

Negotiating Technology Contracts (July 4, 2005)
Have you ever tried to negotiate a deal for software, computer equipment, or consulting services with a technology company? The task can be daunting. Unfortunately, the sales forces of most IT companies are armed to the hilt with techniques to get the best deal for them, and not necessarily the best deal for you. And even worse, most of us computer folk (like myself) have never been trained in the art of negotiation, so it can be difficult to spot a snake in the grass. Before you begin negotiating a technology deal, know what you're getting into.

June 2005

The ABC's Of Dot Releases (June 27, 2005)
Over the years, I've seen various naming conventions for software versions, also known as release numbers. “v2”, “7.0.4321”, “11.3.5432a SR-3”, “RTK0320-R5-32”, “Chicago”. What do these cryptic numbering schemes mean? Which convention should your organization adopt? And more importantly, why should you even care?

Offshore Outsourcing: India (June 20, 2005)
Offshore outsourcing to India is one of the most popular management practices today. Though it is generally spurred by the cost reduction factor, this is just one of the reasons one should consider offshore outsourcing. Most parties who outsource are unaware that Indian Service Providers do not just offer cost effective solutions, but also value addition by improving productivity and quality.

Preventing Schedule Slips (June 13, 2005)
Can Project Managers prevent projects from slipping? Absolutely! And it's actually quite simple if you follow these 4 steps.

Understanding Performance (Part 3) (June 6, 2005)
If you've read part 1 and 2 of this article, you should understand the definition of, and the interdependencies between latency, throughput, and resource utilization. But how do you measure such nonfunctional requirements? And why should you even bother?

May 2005

Understanding Performance (Part 2) (May 30, 2005)
While latency is the only true metric that measures performance from the end user's perspective, it's not the most practical when trying to pinpoint problem areas. Find out why (and more importantly how to) measure throughput and resource utilization.

Understanding Performance (Part 1) (May 23, 2005)
Defining and measuring software quality attributes is critical to the success of any distributed application. Performance is no exception. Part 1 of this 3-part series explores the topic of latency.

Testing Requirements (May 16, 2005)
I'm sure all of you would agree that software requirements are a pre-requisite to developing any large system. However, how do you determine when the requirements are detailed enough to proceed with development? How much details do you need before you can sign off on the software requirements specifications (SRS)?

Don’t Break Out the Champagne Just Yet!!! (May 9, 2005)
Many executives evaluate software development projects with one criterion; whether or not it meets its ship date. Agreed, missing your project milestones could be devastating, especially if there are some legal implications tied to a release schedule. However, the ship date is not the only decisive factor you should pay attention to.

Must Project Managers Be Technically Savvy? (May 2, 2005)
“Must Project Managers be technically savvy?” This topic always seems to cause quite a stir. While some believe that all you need to manage a project is a PMP certification, others are convinced that you can't successfully manage a software development project unless you truly understand the intricacies of the product. Read this article to learn about my (strong) opinion on the subject.

April 2005

Localizing J2EE Web Applications (Apr. 25, 2005)
To successfully compete overseas, you'll need to localize your J2EE application. Whether your customers live in Africa, Asia, Europe or South America, they'll prefer to work with a GUI that's presented in their native language. This technical article introduces JSTL, a taglib that encapsulates I18N capabilities.

When Code Freeze Turns To Code Slush (Apr. 18, 2005)
All things being equal, the sooner you declare code freeze, the faster you'll reach TTM. Slipping the code freeze date will most likely result in an overall schedule slip. But declaring the code as "frozen" when it actually feels more like "slush" will result in an even greater schedule delay.

Reducing Schedule Risk (Part 2) (Apr. 11, 2005)
Reducing Schedule Risk, which I originally wrote over a year ago, describes how project managers can identify and track project milestones to reduce schedule risk. Part 2 of this article describes 5 additional best practices to further reduce schedule risk.

The Top 10 Web Application Security Risks (Apr. 4, 2005)
The Open Web Application Security Project (OWASP) is an all-volunteer group of IT security professionals that produces free, open-source documentation, tools, and standards related to (as their name implies) the security of Web-based applications. For the past two years, OWASP has been publishing a Top-10 list of the most critical Web application security vulnerabilities. The list for 2004 includes (drum roll please)...

March 2005

CPR (Catastrophic Project Recovery) (Mar. 28, 2005)
If you're managing larger software development projects, bookmark this page immediately. I'm sure that at some point in your career, you will need to administer CPR (Catastrophic Project Recovery).

Five Tips For A Great Software Demo (Mar. 21, 2005)
Whether you need to close a sale, gather end-user feedback, show progress to your customer, or simply explain how your product works, sooner or later, you will need to demo your software product. The following represent the top 5 tips I've learned over the last decade to guarantee a great software demo.

Why Great Start Ups Fail (Mar. 12, 2005)
To be successful, software start-ups need to develop technologies quickly. They must be extremely responsive to their lead customer's needs and be willing to add functionality to a product at any given time. However, as they become successful and increase their customer base, their ability to develop functionality at the speed of thought might lead them to failure.

To Build Or Not To Build (Mar. 7, 2005)
Increased management costs, implementation complexities, and frequent requirement changes are elevating the cost of developing software applications. To increase your profitability, should you keep building components in-house or outsource part of your development activities? When faced with various off-the-shelf solutions that meet your needs, should you pick a commercial application or one that's open source?

R&D: The Good, The Bad and The Ugly (Mar. 1, 2005)
Research and Development. R&D. Most of us have heard this phrase without paying much attention to it. As a matter of fact, most of us work in R&D. But what do these two terms mean? And more importantly, what is the implication of doing research versus doing development on your company's bottom line?

February 2005

The Quality Assurance Ratio (Feb. 24, 2005)
Ultimately, the Quality Assurance team decides whether or not a product is ready to be shipped. A release will not become generally available until QA stamps it with their seal of approval. Learn how to ensure that the verification phase of your project runs as smoothly as possible.

The Top 5 Wrong Reasons For Not Hiring Testers (Feb. 19, 2005)
I’ve received tons of emails regarding Quality Is Job #1. Some readers praised the article while others brought up some very valid points against hiring a dedicated team of testers. Finally, a third group, which I’ll refer to as project manglers, clearly didn’t get it. Here are the Top 5 Wrong Reasons why a company should not hire a dedicated team of testers.

I Want It All (Feb. 15, 2005)
The knee-jerk response to prioritizing requirements is to mark everything as a must-have. “I need everything before the product becomes generally available. I want it ALL!” Give me a break.

The 12 Practices of Extreme Programming (Feb. 1, 2005)
Extreme Programming, or XP, is a software development approach built on 12 fundamental practices. Few of these practices are new, but collectively, they reinforce each other and allow you to deliver systems on time, according to specs, and within budget.

The Traveling Product Manager (Feb. 1, 2005)
Various studies – and common sense – indicate that involving customers increases the likelihood that your product will meet customer requirements. But how much customer feedback really makes its way into your product?

January 2005

Forecasting Support Costs (Jan. 17, 2005)
Did you know that maintenance accounts for 50% to 80% of the overall product cost? Well, it does! And unfortunately, most of us are terrible at estimating the effort required to support a product once it becomes generally available.

Project Heroes (Jan. 15, 2005)
Project heroes. We've all heard of them. Some of us have even seen them. My question is, how should we manage them?

Are You a Project Manager Or a Project Mangler? (Jan. 10, 2005)
Which one are you? An effective project manager, or someone referred to as a project mangler? Find out with our Top 10 Signs You're a Project Mangler.

Quality Is Job #1 (Jan. 7, 2005)
Should organizations developing software (a) have a team of dedicated testers, or (b) make the developers solely responsible for the quality of their application? Based on my experience at companies that have used both strategies, the answer is clearly (a). Find out why.

Software Quality Attributes (Jan. 5, 2005)
In addition to the functional requirements are other requirements that don't actually do anything, but that are critical to your project nevertheless. Make sure you consider these “quality attributes” in your architectural design, or you throw away your code when it doesn't meet them - your call!

Staff IT (Jan. 1, 2005)
We all know that adding more resources to a project does not allow you to indefinitely compress its schedule. Follow these guidelines when staffing software projects.

One Size Fits All (Jan. 1, 2005)
One of the most common problems for overly optimistic project schedules is the project mangler's failure to account for all the activities required to complete the project. Don't neglect to account for derivative tasks

December 2004

Tracking Requirements (Dec. 21, 2004)
Managing larger software development projects requires a lot of discipline. No matter how many times you've read the specs, unless you have a stringent process for tracking requirements, some of them will fall through the cracks.

Reducing Schedule Risk (Dec. 15, 2004)
While there is no silver bullet against overly optimistic schedules, you can reduce schedule risk through Project Milestones, a best practice that requires you to identify and track significant points or achievements in your project.

It's Just a Button (Dec. 15, 2004)
Do you honestly think that this change request will take 5 minutes? Think again!

Eat Your Own Dog Food (Dec. 11, 2004)
Eat your own dog food is an idiom describing the act of a company using its own products for day-to-day operations. Learn how eating your won dog food can help you become an industryleader.

First Things First (Dec. 7, 2004)
If you're development schedule is aggressive, you're inevitably going to cut some features. The question is, are you cutting features that will cost you a sale?

To Release or Not To Release (Dec. 5, 2004)
Deciding when to release software is a tough decision. There are drawbacks to both shipping too early and too late, and unless you have a strategy for determining when software is ready to be released, you could be damaging your company's bottom line and reputation.

The Daily Build Process (Dec. 2, 2004)
A daily build process ensures that the load is consistently stable and developers are not committing code at the expense of quality. Learn and apply this process in your organization - you won't regret it!

R. U. Dunyet (a.k.a. Red) (Dec. 1, 2004)
Don't ask your team members vague questions like "Are you done yet" and then walk away. Drill the developer for more details if you want an accurate status of your project.