A hot and important topic lately has been project management. As a professional systems analyst for more than 10 years - I’ve seen projects that have had zero project management to those that have been articulated with the utmost precision.
The one item I believe when starting a project is to know what you want. Many times I’ve seen managers and end users state they want to start a project up to do X - but they really want a project that does Y. Usually however this happens when technical teams tend to over sell themselves on what exact expectations they can in fact commit to. Also, starting a project and gaining support from the right group of people is vital. If key users we’re not asked about the project beforehand then that right away is a project going in the wrong direction from the start.
Thus, a carefully constructed scope plan with the details of what will be accomplished is imperative.
Next, the project should outline what tasks need to be accomplished and the stakeholders behind those tasks along with the estimated date of each main deliverable. After the scope is approved from a board of directors or management committee - a kickoff meeting of key members should be accomplished. At this meeting - proposals can be signed, key parts gone over after they have been previously reviewed etc.
After this phase, key users should be interviewed to find out their likes/dislikes with a current system or process.
Then the project will need a technical outline which usually is completed by a business analyst or systems analyst. I tend to find that this document is very important to the success of not only meeting deadlines but also meeting budget. Usually - if the application I am working on involves a vast array of screens - I will layout and explain each element on the screen along with its name and even where in the system it will be stored. This way, in the end the amount of surprises uncovered is limited. Such a document is then handed to a coder or team of coders to actually start the coding process. I recommend at this step to start documentating what is being done with the system so that information is not lost in the information flow. Additionally, starting the documentation at this step will create less work later on in the system development life cycle as remembering how some key element was done will already have been captured, making the final piece of documentation easier to write and understand.
Now, during the build phase - the main project manager or director should obtain weekly or monthly progress reports of what tasks have been accomplished, those that are in progress and the financial state at present point in time (is the project under or over budget at this point). I found that what works well for this stage is a high level bulleted point list of items in a document - then refer to the financials as detailed as possible in a spreadsheet application. I recommend breaking this process up because I’ve found that sometimes a project manager or director may need to send just the numbers to either accounting or even a Chief Information Officer (CIO).
Finally, a alpha phase of the software/process should be tested with a test script by both technical and non-technical users. From my perspective what I tend to do here is be a user for the day and go through step by step the activities they will likely be performing and thus I list each item I did step by step in a test script so that those testing can mimic a user as close as possible. In my line of work - usually I want users to be able to create/read/update/delete (CRUD) information.
Once the first round of testing is completed - a beta phase will follow which usually includes deploying a system to a group of key users (sometimes I even give the users my test script so not only are they testing the system but at the same time learning how to use the system). At the same time a beta is being rolled out, I recommend creating a plan of action for go live.
After the beta stage is completed then a formal traning session should take place by either a key user or a trained educator whom is knowledgeable enough on the system and it’s processes.
Then a final review of the full system should take place (by both those in information technology and those whom are are users so that two perspectives of knowledge are brought forth). Once a agreement has been made that the system is done and functioning as desired then the project can go live.
The last step is to review and write a final documentation of all processes and additionally plan on doing additional maintennace/addons to the life cycle - which in some cases is never ending as users will find bugs (their is no such thing as the perfect piece of software) and want enhancements to further functionality.
The one item I believe when starting a project is to know what you want. Many times I’ve seen managers and end users state they want to start a project up to do X - but they really want a project that does Y. Usually however this happens when technical teams tend to over sell themselves on what exact expectations they can in fact commit to. Also, starting a project and gaining support from the right group of people is vital. If key users we’re not asked about the project beforehand then that right away is a project going in the wrong direction from the start.
Thus, a carefully constructed scope plan with the details of what will be accomplished is imperative.
Next, the project should outline what tasks need to be accomplished and the stakeholders behind those tasks along with the estimated date of each main deliverable. After the scope is approved from a board of directors or management committee - a kickoff meeting of key members should be accomplished. At this meeting - proposals can be signed, key parts gone over after they have been previously reviewed etc.
After this phase, key users should be interviewed to find out their likes/dislikes with a current system or process.
Then the project will need a technical outline which usually is completed by a business analyst or systems analyst. I tend to find that this document is very important to the success of not only meeting deadlines but also meeting budget. Usually - if the application I am working on involves a vast array of screens - I will layout and explain each element on the screen along with its name and even where in the system it will be stored. This way, in the end the amount of surprises uncovered is limited. Such a document is then handed to a coder or team of coders to actually start the coding process. I recommend at this step to start documentating what is being done with the system so that information is not lost in the information flow. Additionally, starting the documentation at this step will create less work later on in the system development life cycle as remembering how some key element was done will already have been captured, making the final piece of documentation easier to write and understand.
Now, during the build phase - the main project manager or director should obtain weekly or monthly progress reports of what tasks have been accomplished, those that are in progress and the financial state at present point in time (is the project under or over budget at this point). I found that what works well for this stage is a high level bulleted point list of items in a document - then refer to the financials as detailed as possible in a spreadsheet application. I recommend breaking this process up because I’ve found that sometimes a project manager or director may need to send just the numbers to either accounting or even a Chief Information Officer (CIO).
Finally, a alpha phase of the software/process should be tested with a test script by both technical and non-technical users. From my perspective what I tend to do here is be a user for the day and go through step by step the activities they will likely be performing and thus I list each item I did step by step in a test script so that those testing can mimic a user as close as possible. In my line of work - usually I want users to be able to create/read/update/delete (CRUD) information.
Once the first round of testing is completed - a beta phase will follow which usually includes deploying a system to a group of key users (sometimes I even give the users my test script so not only are they testing the system but at the same time learning how to use the system). At the same time a beta is being rolled out, I recommend creating a plan of action for go live.
After the beta stage is completed then a formal traning session should take place by either a key user or a trained educator whom is knowledgeable enough on the system and it’s processes.
Then a final review of the full system should take place (by both those in information technology and those whom are are users so that two perspectives of knowledge are brought forth). Once a agreement has been made that the system is done and functioning as desired then the project can go live.
The last step is to review and write a final documentation of all processes and additionally plan on doing additional maintennace/addons to the life cycle - which in some cases is never ending as users will find bugs (their is no such thing as the perfect piece of software) and want enhancements to further functionality.
Comments