Software Project Management

Are you a PMBOK® slave? Will the real Project Managers please stand up.

“The Project Management Team is responsible for determining what is appropriate for any given project.” (PMBOK® Third Edition)

Distinguished Project Management Professionals know how to tailor frameworks and models like PMBOK®, SCRUM, RUP®, and others, to benefit the delivery of their engagement. 

If you are a mere model bound Project Manager, then you will find it increasingly difficult to keep up with pressures in software solution delivery. The latest advances in Software solution implementation forces Project Managers and their teams to be agile, flexible and innovative in their approach to delivering and evolving IT solutions. 

In this Blog entry I am discussing some of the more recent imperatives for successfully managing Software and other I.T. solution implementations. 

The Project Management Institute has done a great job of providing an overview of good project management practice in their publication PMBOK® Third Edition. However, I am hoping to color in some of the framework with practical scenarios from I.T. Project Management perspectives.

Knowledge Application

Data are mere symbols, words and sentences with no relation, application or context. The words “Apple” , “Street”, and “Ten” are examples of data. 

When data is linked through association and context then it turns into information. When “Apple”, “Street” and “Ten” is linked together through a descriptor “Address”, it obtains context and becomes information. For example: There is an address: “Ten Apple Street” to be found. 

Knowledge is the act of applying and using information for a specific result, purpose or outcome. The address: “Ten Apple Street” is where my client resides. I need to know the address to find my  client. For example: “I am on my way to collect the sales order from my client at Ten Apple Street.“

Experience is the learning gained from knowledge application. In other words, you have to do something with your knowledge to claim experience. For example: “I found my client at Ten Apple Street, and collected the sales order”. 

Therefore, I now have utilized data, information and knowledge to achieve an outcome. Once the outcome is achieved, I am an experienced Professional at collecting sales orders from the client at Ten Apple Street.

In Project Management, like all competencies, one is required to go through the above process to become proficient in what we do. Merely knowing and understanding models (data, information) is not enough. One needs to apply this information during execution for a purpose to gain knowledge. Once applied, our learning turns into experience that becomes part of the make-up of a competent Professional. 

If you strive to become a proficient Project Management Professional, then seek out opportunities to test and verify the information from available models. These actions will equip you with knowledge and experience of what to do, or not to do, during an engagement. It will form part of your Professional Toolbox that distinguish you from other similarly qualified people.

Ultimately, clients reward successful delivery. Your knowledge and experience will chart how smooth the road to this delivery will be for the participating stakeholders.

No End in Mind!

One of the hardest, yet most important aspects of I.T. solution implementation, and in particular software implementation is that usually neither the team nor the customer have a clear detailed perspective of what or when the end result will be from a project or initiative.

There are usually clearly defined objectives and high level requirements. However, no one has an exact picture of the finished product or when the product will ever be finished. 

Even if they attempt to construct such a picture, it will most probably be out of date by the time it is “completed”, or the business will have moved beyond its requirement for the solution in the first instance. A new set of requirements will be in play, and as Project Manager, you will have to re-group and start again.

Several additional reasons apply:

• The business imperatives may change during the course of the implementation, and this has an influence on the final outcome of the project. Time and time again it has shown that software solutions needs to be implemented quickly (within three months) else the project risks to be out of pace with changing business demands. For example: a specified order entry solution may be modeled on current business processes. These processes change over time. If the solution is not implemented while the current processes are applicable, it may find itself out of date before it is even deployed. Alternatively, the project will have to play catch-up with business at a huge cost. Some solution implementations may never see the light if they cannot keep up with changing business demands.
• The technology offers flexibility that allows for a range of options available to the engineers of a solution. These flexibilities can distract or divert some of the initial focus for the solution. A new feature discovered during the process of implementation may reset and influence some of the solution outcomes. For example: Part through an implementation, the engineers may discover a function that eliminates or introduce architectural flexibility that is useful, however not imperative to the initial envisioned solution outcome. If the engineers are distracted to implement this function “in case” it is needed, you may find that you are either undoing previous work, or introducing more work and unnecessary complexity into the solution to be delivered.
• The tools are constantly changing. I.T. vendors are always evolving their products and this introduces external change factors during the course of a solution’s implementation life cycle. For example: While implementing a particular software package, the vendor may release the next version of the platform. The project then has to decide if it incorporates the upgrade at a risk to the project budget and timeline, or leave the client with a post-project upgrade task that may make the project solution initially less useful.
• I.T. solutions tend to be custom to a particular customer’s business or industry. This means that whatever your team is building is probably unique, and your product is most likely the first and probably the last to do an implementation exactly like the one you are doing at present. This means your stakeholders are all learning while they are on the project. This learning is bound to cost the project time and money beyond the initial planned budgets. For example: During a web site implementation, the client may discover that their branding strategy needs some additional work to make it more presentable online. While the user interface design takes place, a number of iterations may be required to accommodate the client to find and finalize a look and feel for the site that matches their brand identity. Each version provides the client with feedback/learning that needs to be accommodated through subsequent iterations. 

The best way for an I.T. Project Manager and his team to deal with this challenge, of not knowing how the end product will be, is to adopt agile and flexible work practices that leaves enough time for all stakeholders to learn and change their minds. 

Use small teams. Do a few things at a time (the most important functionalities or architecturally significant use cases). Do it quickly. Learn from what is done, and allow all stakeholders to evaluate the outcomes constantly. 

Be prepared to re-evaluate all assumptions on scope, budget and timeline regularly. Accommodate and embrace change. Be ready for a lot of change. Have your Change Management and Risk Management plans rock solid. 

Time-box deployments through iterations or work packages that allows stakeholders the opportunity to evaluate the current position against possible future expectations. Be ready to change the scope at each one of these checkpoints.

Software is Never Finished

Many organizations mistakenly assume that once a project has deployed a particular I.T. solution or version of software that the activity ends. 

I.T. solutions are not like cars or appliances that once they are built they remain in the same relative state with reasonable maintenance until they are one day retired from service. 

Rather, I.T. solutions, and software in particular are always evolving. More functionality is introduced, and old functionality is changed. The use of a solution is evolving, the business it serves is evolving, and as a result, a solution may change from month-to-month, year-to-your. It is integrated, interfaced, incorporated, upgraded, etc.

Therefore, as I.T. Project Manager, you may find that once you’ve started an I.T. Project, that all good intentions to have a defined start and finish date may fail. Three years later, and in some cases eight years later, you may still be building, changing, enhancing and upgrading the same solution that you’ve hoped will take only six months to build and deploy. 

As mentioned above, the end result in three years time may prove to be quite different from the envisioned end point at the start of the engagement. 

Conclusion

Models for managing the construction and deployment of I.T. solutions are important and useful. However, know that experience with a particular processes is imperative to understand the benefits and weaknesses of each model. 

There is no substitute for common sense while managing an I.T. solution deployment. Merely showing PMP behind your name in no way can show that you know your way around I.T. Project Management. 

Software development projects in particular pose challenges with ambiguously defined end results, challenging rapidly changing requirements, immature technology, and an industry that thrives on complexity with Professional proficiencies that leave a lot to be desired.

Remember that no model will save a project. Competent I.T. Professionals and their Project Managers that has learned how to use these models when and where appropriate will ultimately succeed in running the I.T. solution implementation gauntlet. 

If you have a weak team with inexperienced model driven management, then prepare for expensive I.T. project management and pain.

As always, your comments are welcome.

Hendrik van Wyk

Comments:

Hendrik, 

I just wanted to tell you that I enjoyed your blog on SW Project management.  You are right that preoccupation with models and theories can get the PM in trouble. 

In my experience, It doesn't matter what process you employ to deliver your project -- Agile Development, Extreme Programming, Waterfall, Spiral, Seat-of-Your Pants, Rapid Application Development -- they all have merit. Keep doing  whatever works for you. However, there are basic principles or universal guides that the effective PM uses to shepherd projects through any process. 

You will find some practical tips that illustrate that claim here:  www.projectEZ.com.

John M. Langlois, PMP®