A large part of this site is dedicated towards software project management. I get a lot of question how this differs from general IT project management. Actually, it doesn't. In 90% of IT projects, software makes up a large part of the effort. Next to, hardware, networks, and other infrastructure related components. So, in a sense IT project management has a broader scope.

However, the general techniques, outlines, and processes are the same. By focusing my course on software projects I can put emphasis on typical application software related issues, like user requirements, but that's all. If you are looking for a IT project management guide, I highly recommend my course.

Related Posts
3 Steps Towards Becoming An Agile Project Manager

Why is this basically the same… I need to go a step back to explain this properly.

Recent years a lot of complains about current project management practices have emerged. Methods are too rigid, too centralized in respect to planning, etc. (good examples of these methods are PMP and Prince 2) This even has resulted in a new breed of methods, agile a.k.a. light weight a.k.a. lean methods. Examples for project management are Last Planner (construction) and SCRUM (software development).

However, the replacement of one normative method for project management by another may not me the answer to the problems projects are faced with. Different circumstances may require a different approach. If you need creativity to solve a problem or to create a design, you need an easy going, stimulating approach; if you are running towards a deadline to get in to production, a rigid, centralized controlled environment is more the way to go. Depending on the environment and general circumstances a project manager should construct a process and organization that serves him or her best.

Key question is "what make up the circumstances?" Without hesitation I would say "people". In my personal experience all major problems concerning projects are caused by human stuff. Intuitively I would state that the source of the trouble lies within the interest of the individuals and (the lack of) information/knowledge. As humans are controlled by their own fears and wishes, it's more then logical that if they are working under a project, they use the same mechanism.

And it is just this assumption that form the basis of The Microwave Way to Software Project Management. See, the subject is software, the application area very general.

It's so nice to talk about new ways of doing business, it's so enlightening to discuss neat futures for an application, why spoil the fun with numbers? Simple. Because you have to pay. Most businesses today still have to make a profit, so 'cost' is an issue.

Why then this 'total cost of ownership'? Again, simple. Because a lot of times only part of the cost is considered, and after a while the brown stuff hits the fan; unexpected bills turn their ugly heads up. If I learned one thing in all these years, it's that managers never like unexpected things, especially the ones of the paying kind.

When a company decides it's time for some information system, normally someone is assigned to fill in the answer to the urging question: which system? I assume, you are that one, the poor sucker responsible for pushing the car up onto the mountain.

From day one, you lay down this issue of cost. From day one you should make everyone aware you're going for the full Monty, the whole enchilada, the total cost. If you tell a business manager software will cost $10,000, he will assume that's what he has to pay in the end. You will assume he knows you're talking about just the software licenses, and not about hardware and infrastructure, and not even beginning to top the subject on implementation cost.

The first day you have no clue about the cost. At least you don't have a clue about the amount. You do know buying and implementing software will have several components that make up the cost. You know you need something it runs on, you know you need some programmer to interface to different systems. They don't.

By laying down all the cards from the start, you avoid surprises. You will get valuable helping hands from the managers if you tell them what your questions are from day one. You will be amazed.

And if you aren't sure, you do know, after finishing this tutorial, you can rest assure. You will be able to make a good and informed impression on your first date with the one with the wallet.

So, you are going to select some software. I don't mean an action game for your kids, but I'm talking about a real life, heavy-duty business application. Actually, the hard part is deciding which system to acquire anyway. It's so hard, we even have a name for all the steps together: the software selection process or acquisition process if you like difficult words.

And people are making it difficult, trying to make it look like a science. Let me make one thing clear, right from the start: the actual judgment on the selection is difficult, the only thing that really can help you there is experience, the process itself is easy and straightforward.

In this guide I will describe the first part of the software selection process, and my own experiences with it. It is actually the first round, of the total of two rounds that will bring you to your final choice: the request for information. The second part will be described in a future volume 2 of The Microwave Way to Software Selection.

This is not THE only way to do a software selection process. However, it's simple, straightforward and effective: the microwave way.

2 The Steps

The software selection process is a two step trip: first you create a large list of candidate vendors (the long list) who you will send a request for further information. You select the best suited for you (the short list) and go with them in detail on your needs (request for proposal).

The steps covered in this tutorial are the ones to get to the short list.

* Define your needs

* Define your selection criteria

* Create the long list

* Create the request for information

* Evaluate the responses

* Create your short list

You see, nothing you can't handle!

Relevant links

Software Marketing Disasters

Custom Software Development
Custom web applications bring Web sites to life. Stylus Systems can develop a software application from the ground up, providing you with exactly what you need, not just what we have available.

Offshore Software Development
MachroTech is a leading offshore software development company specializing in eCommerce solutions, custom software development and application integration. FREE Consultation.

Aventail clientless ssl vpn server
Clearview Systems supply Aventail SSL VPN servers to provide secure remote access to any resource from anywhere.

Artifact
Artifact helps companies manage offshore and onshore software development outsourcing engagements by providing an integrated set of project management, application life-cycle, and dashboard tools in a securely hosted, subscription-based service.

Between 40% and 60% of software failures and defects are the result of poor software management and requirements definition. In plain English, this means that about half of the problems encountered could have been avoided by making it clear, from the very beginning, what the customer expected from the respective project. This is to say that the programming was fine and the developers did their job well – only they did a different job from what they were supposed to.

The definition of a successful program is that it is 100% compliant with its initial requirements. But it those requirements contain mistakes, are unclear or poorly defined, then there is very little one can do to correct the problem later in the process. So, a bit of advance planning simply doubles the success changes of any software project.

The persons in charge with writing the requirements should be the project managers and the team in charge with software engineering, all the stakeholders, the clients and the end-users. Writing good requirements takes time and practice, and, even with all the new tools designed to help you, it will not happen overnight. You need a good, clear, organized mind, good programming knowledge (because you'll need to know exactly what your team of developers can do, and you need to make sure that you speak the same language with them) and, to a certain extent, good people skills. You will need to get in touch with the clients during this period, and to find out exactly what they want and how they want it. Some of them are not capable of explaining what they need, others don't have the time to meet you and look over the drafts, other thinks they know better and they give you all the wrong ideas, and others will simply be very happy to approve your specifications without having a second look at them. You need to persuade all of them about the importance of this step, hold long, boring meeting, and then "translate" their needs for the programmers and developers. If customers or end-users are not available, despite your best efforts, you can use "surrogates" to simulate the actual users.

Make sure you remain in close contact with the client for the entire duration of the process. Their needs may change, or they may find out about something they forgot to tell you in the beginning – so inform them that you will always be available to meet with them and look at all the options again.

Also, the quality testing department needs to be informed about the requirements from the very beginning, because they will design their tests accordingly, and also they may have some details about what can go wrong in some cases.

One of the biggest issues is the time you have available for writing the requirements. Sometimes, when the deadline is very tight, the developers may start working before you completed the requirements, and this can cause a lot of problems later on.

The process of requirement management ends when the final product is shipped, and the customer is fully satisfied by it. However, the fewer modifications your requirements will suffer, the better for everybody. You should be able to trace your requirements all the time, and we'll have a look, later on, at the tools that enable you to do this.

In some cases, when a client comes up with an additional issue, it may be too late to change a requirement or ad a new one – the workload and the costs are simply too big to make it worth it. This remains subject to negotiation between you and the client – but your task is to know exactly what would be the effect of implementing new requirements, and to translate it into the language of the client (meaning that the client may not be receptive when he sees how many code lines need to be changed, but he may understand when you tell him how much this will cost).

Tracing requirements also involves additional tests, performed from time to time, to insure that the process runs smoothly and errors are identified and corrected early on. When faced with a big project, you may have different sets of requirements, some that apply to the entire project, and some for parts of it. When a certain design is implemented for a certain requirements, make a note about the effects and the alternatives – it may be useful for future projects (or even for the same project, if the client is not satisfied with the result).

So far, we've seen what software requirements are. In the following sections, we'll show some tips and tools about what good software requirements are. If this section is your responsibility, the wisest thing you can do is to get the IEEE Software Engineering Standards Collection. At 400 dollars, it may be somewhat expensive, but it will give you a lot of useful details about terminology, processes, the quality assurance and the user documentation needed. Also, the standards are conveniently given for each separate unit of the process – the specific part about software requirements specification is IEEE STD 830-1998, which describes the content of good requirements specifications and provides some useful samples. The guide is designed for in-house software, but it can be used for commercial software as well, with minor changes. Another useful reference is the "Standards Guidelines and Examples of System and Software Requirements Engineering" by M. Dorfman and R. Thayer, a compilation covering all the major standards (IEEE, ANSI, NASA and US Military). These are all flexible instruments, and should be used as such.

The Microwave Way to Software Project Management is a free guide to help you get the hang of project management stuff in no-time. The entire course consists of seven chapters that are written especially for those who hate long and boring books.

If you are new to Project Management, please watch this 15 minute video first, and afterwards enjoy this tutorial.

Chapter 1: Mindset of the software project manager
Stakeholders are all the people involved in a project, the customer, the supplier, the boss, the user, you name it. As a project manager you have to deal with them; it's even worse, they will determine if your software project will be a success or a failure. This first chapter will describe the image a software project manager should have engraved in his mind. If you see it, you will surely recognize it. It's simple and short, so much easier to keep in your head then a huge binder with methods.

Chapter 2: Project Intake
Ever got a present where you thought "what is this?" Ever got something from your superiors nicely wrapped in a paper with in neon letters 'project' on it, where you thought "what?" Then this chapter is surely for you. Problems, ideas or just plain stupidity are quickly labeled 'project' and handed over to a project manager. The intake is to clarify what is meant so the project manager is not getting the blame.

Chapter 3: Requirements determination
Whatever you do, what ever you make,you should know what to do or to make. After an intake the global contours of the project are outlined by goals and scope. You should get more specific though. It's this getting more specific that requirements determination is all about

Chapter 4: Requirements validation As a kid I played this little game at school we called 'telephone line'. Twenty kids were hurdled up into a circle. One started by whispering a sentence in the ear of his neighbor, so the other kids couldn't hear what was said. The neighbor would say the same sentence to his neighbor, and so on, until the sentence was 'round circle'. The fun of the game was comparing what the last one had heard with what was originally said. Mostly, they didn't even come close. During the project the requirements stated at requirements determination should be validated. This validation goes two ways: are we meeting the requirements, and are the requirements still valid. This section handles the requirements made to the product part of the project.

Chapter 5: Project Progress
In Holland we have this huge (200km) ice-skating event, the "Elf Steden Tocht" which means "Eleven cities tour". On the course are several check points, which in fact are the eleven cities, where you have to get a stamp. Getting these stamps is very important. Actually, the race is about passing all the checkpoints.In a project it's all about getting the approvals to keep on going. This section handles giving feedback on the requirements made to the process. Are we still within time and budget, and are the project constrains still the same

Chapter 6: Risk Management I cannot tell you what the future will bring. No one can, although some people believe they can. This whole project thing is based upon assumptions and estimations, on guesses and hunches. Sometimes we are wrong. In a project we have to deal with this as a fact of life. Enter "risk management". A risk is the possibility of loss of some kind. It's all about what can be different from what we believe right now. Not just what can go wrong, but possibilities can arise also if the future brings not what you think it will. "Dealing with uncertainty" would be a good subtitle for this section of the guide.

Chapter 7: The Bigger Picture
This final chapter in this project management course will cover two aspects of doing projects in a larger context, your organization. The aspects are how to handle policies issued on what systems you may use, and how it should be constructed, and how you can introduce a "project approach" into an organization in such a way, your own job as a project manager will be more effective.

Relevant links

Deliver Good Customer Service that Customers Demand
Why is good customer service becoming so important these days? It's simply because customers, who are not getting quality support, are turning their backs to the sites that do not deliver.

Project Perfect project management software and consulting
Project Perfect provides white papers, project management software and consulting services on project management. Our software can help manage risks, issues, action items, benefits, scope, budget and expenditure, checklists, documents and much more. Integrated with Microsoft Project.

Mind Tools Project Planning and Management Section
This page shows you how to use a wide range of skills which help you to schedule and manage projects.

Software Project Management Classroom Course
3 day project management course in UK for people involved in software and other IT projects.

Management Resources
Management related news, books and web resources.

Computer Technical Tutorials & More
A premier directory for computer technology and related tutorials, subjects, and websites providing dynamic user ratings and hit counts to all links. All link submissions are free.

Project Management Resources
Thousands of content-rich Internet resources in over 50 different business categories from Accounting and Project Management to Writing.

Surrex Solutions Corporation
IT Consulting. Project Staffing Management Information Technology Services Career Opportunities Staffing Services Project Management Software Development Contract Programming Employment.

Distance,online,computer based learning and training
Target Global Campus are dedicated to providing current and continuously updated distance learning solutions using the most educationally sound online learning and computer based training available.

Dutch Project Management Directory