http://gircrazyp.friendlinkup.com/ How to Create and Implement Successful Projects en http://gircrazyp.friendlinkup.com/2008/10/09/project-management-processes-phases-and-personal-notes.html One question I am requested often is how I manage my SharePoint projects, what stages I go through as well as how I perform/manage each phase of a project. This is probably something you already do, but perhaps it’s good to see some examples of how other people manage projects, so feel free to read along. Personal Note: This is a high level summary of what I do in a typical project as well as is not every individual item. SharePoint is also mentioned throughout this article because of the fact that it is the technology I an estimated all often utilize when working on projects as well as organizing information. Before the Project Starts Before I start a project I create areas to capture knowledge (KB, as well as lessons learned), following that I begin the process of the project itself. This is important to do right at the start because of the fact that even during the pre-project phases you can come up with some interesting notes, concepts, or lessons learned. Right now I at all times do this knowledge capture using SharePoint with a mixture of wiki’s as well as related concepts. So this area is already built as well as all I require to do is create a ‘project’ as well as ensure the ‘customer’, ‘client’, as well as ‘area of business’ represented is also within the knowledge area to ensure anyone who comes up with something new can create articles, upload documents as well as basically create content that shall be associated to that project, client, or business area. Personal Note: I ordinarily break a project down into the following phases. Every project, regardless of the size. The good thing is that I do NOT enforce specific templates on behalf of each phase. I love the idea of templates in that they can save you time as well as certainly have some that I can manufacture utilize of, but it’s important to not force yourself to fill out a document as well as certain content placeholders just because of the fact that ‘its part of the template’. This can often create confusing statements, is a waste of effort, as well as really can detract from the important parts of the document. Definition Phase Domain Analysis I at all times start off with some sort of domain analysis. That is analysis of the current environment, configuration, as well as system that is in place. How do things interact with one another? What applications already exist? What version are they? How are they used? The results of this analysis shall should contain an overview of the current servers, third party applications, shared service providers, configurations, as well as web applications, as well as existing site collections. I personally like to utilize excel documents on behalf of this (I know I could utilize SharePoint lists as well as may consider doing so in the future). Once these have been identified as well as cataloged the next phase of work can begin. Requirements Analysis Based on the objectives as well as target audience a series of business requirements must be retrieved. These requirements can come from business stakeholders, potential administration, as well as end users. It may be necessary to hold requirement gathering workshops with various involved parties in order to better understand how people would like to utilize the eventual system as well as how the system can provide them the an estimated all benefit. Important things to note from personal experience during the requirements gathering phase: Involve every stakeholder in this requirements gathering. Even if it’s just to briefly discuss the requirements you have gathered from a high level. This shall permit them to feel more involved in providing any input as well as requirements they might have as well as ensures that later when the system is being developed or implemented there are no significant surprises or missed requirements. Ensure you document the motivational reasons on behalf of a requirement as well as the requirement itself. This can really help you or the individual drafting the technical specification determine the correct solution on behalf of that individual requirement. This sounds simple but you would be surprised at how numerous people just document Requirements 1A-200C as well as forget to explain why these requirements even exist. This also can help you if later down the road someone says why did we do this? Prioritize the Requirements. Its important to identify ‘must have’, ‘would like to have’, as well as ‘if there’s time’ categorizations on behalf of every requirement. Its also a good idea to have further priority information. This additional priority information combined with the motivational reasons should manufacture it clear where you require to spend an estimated all of your time, or manufacture sure that the solution absolutely covers these areas. Functional Specification These requirements as well as the knowledge you have gained from the client now allows you to create what is often referred to as a functional specification. This outlines how the users anticipate to interact with the system, outlines their requirements as well as ensures that unanswered questions are resolved. Some important points: Only one person should OWN (and write) the functional specification. This is very important. This ensures one person is responsible, one person can be referenced on behalf of information, as well as that the creative ideas as well as concepts represented (while based on numerous peoples input) is written as well as communicated by one individual. If the project is very large as well as this doesn’t seem feasible on behalf of one person break it into two smaller projects as well as have each person write their posses specification on behalf of a part of it. Always have a developer or someone who shall be writing the technical specification review your functional specification. This review should help point out gaps in the document, or knowledge so that you can interact with the client as well as retrieve answers without disrupting the technical specification process. (You don’t desire the technical specification to start until the functional requirements have been hammered out if at all possible, that way you won't potentially require to redo some technical specification work if requirements change.) There should never be a question mark in the functional specification. Everything written in here shall be signed off on as well as it should be complete. Ensure if you aren’t sure about something that it is classified as out of scope. The functional specification must not contain particulars on how it shall be technically implemented. This is the kind of information that should be contained in the technical specification which is developed from the functional specification. The functional specification should contain a ‘from the user’ perspective. If possible provide scenarios. Scenarios are one of the easiest ways on behalf of any reader to understand something. It gives a real world example on behalf of how something works as well as can provide addition insight into why, as well as how it could be done. Make it READABLE. This one is very simple. If possible manufacture it fun to read, or if that’s not possible ensure the language it is written in is to the point as well as easy to read. Never complicate it with business jargon or add additional adjectives to describe something just because of the fact that you desire to sound savvy or the document to seem ‘more professional’. Include a sort of ‘executive summary’ or overview that is short, to the point as well as describes high level what the functional specification outlines in more detail. This shall permit those who don’t require to read the entire thing to still understand the information it contains. Include as much detail as possible. If you outline that there's a requirement on behalf of notification to be sent to a user manufacture sure you write exactly what the notification shall say, as well as identify any options or actions that can result from this notification. Design as well as Architecture Technical Specification as well as Architecture Developer or Architect creates a technical specification or a ‘design doc’ as often I hear it being referred to as. Content contained in the technical specification can include how the solution shall be built, what technologies shall be used, what the server requirements as well as hardware requirements are, stuff like that. Provide specific instructions on behalf of how things shall work as well as if possible their dependencies. As an example if you know your end solution shall an estimated all likely utilize a notification service that shall require email provide this information in a clear manner so that upon sign off (or even before sign off) the analyst, consultant, or account manager assigned to interact with the client can begin getting you the things you eventually shall need. Graphic Specification, as well as Visual Design (or Screen Engineering) With the technical specification complete we can now document how the screens, components, messages, as well as features shall look to the end user. To be honest, I am not a graphic designer, or even really a designer. So my advice on this area is going to be limited in scope. What I would recommend here are these few things: Make a specific note that these are recommended screen designs but that the end result may differ slightly. The initial screen designs rarely capture every single aspect of the solution as well as do not get modified at some point. They are the guideline as well as really help clients, developers, as well as anyone else involved understand what to expect. Since this is setting their expectations manufacture certain they realize that minor adjustments may be necessary to manufacture it more functional or user friendly down the road. Notify the client of any graphical changes. If you do manufacture a graphical modification or desire to manufacture one at the end of the client has signed off as well as the project has started in earnest, manufacture certain you notify them. Get them involved even if it’s not an active role to manufacture sure that it reduces potential trouble down the road. Do not add additional functionality to manufacture things look nicer. Keep in mind you have a limited amount of time on behalf of this project. The designs should mirror what is outlined in the functional as well as technical specifications. Often (by accident) a graphic designer may adjust something to manufacture it look nicer but not realize the implications that adjustment can have. It’s important to think about everything that might be effected by visual adjustments. Have technical personnel review the design. Don’t just have the analyst, or consultant review the design manufacture sure the developers also review it. They may point out inconsistencies or potentially better ways of presenting information or taking user input. They know the tools available to them, as well as in SharePoint as an example shall know the effort required to style as well as adjust certain items, over others. (Example changing the way a list presents information as opposed to adjusting a master page.) Development Plan as well as Project Plan Based on estimates on behalf of how long tasks should take as well as a logical rational breakdown of responsibilities create a project plan. I ordinarily utilize Microsoft Project because of the fact that it makes it easier to modify later, tell what’s on the critical path, manage resources across projects, as well as so on as well as so forth. Important Note:Don’t forget your communication, training as well as support plans! These should be all elaborated on as well as clearly identified at this stage in conjunction with their time as well as associated cost. SLA agreements might be created here, or communication plans. So retain in mind that while I am only describing briefly the project plan as well as development plan that there are a great numerous other potentially required plans as well as agreements necessary before you should transfer beyond the planning stage. Create a development plan based off of the technical specification as well as the design specification. Ensure all estimates, times as well as tasks have been delegated under this plan. Depending on the environment I like to utilize a RACI model on behalf of both plans. RACI in this case stands on behalf of Responsible, Accountable, Consulted, as well as Informed. Basically on behalf of each developer/team member I manufacture sure that it is clear whether they are responsible, accountable, require to be consulted, or require to be informed of each as well as every task. This is ordinarily pretty easy to do, but it makes sure that everyone at all times knows who needs to be consulted with, informed of changes, or who is accountable on behalf of a task being complete etc. Personal Note: This doesn’t at all times manufacture sense. There are some teams that may take offense to the concept, as well as it isn’t at all times the easiest thing to retain track of. However in important projects I trust this is an integral piece because of the fact that without a RACI model implemented you can't at all times determine what might have gone wrong, or how it can be resolved in the future. Personally I at all times utilize one as well as fill it out regardless, but it is best if each member has input as well as agrees to the RACI on behalf of each task. One thing I also do is often utilize Project Server to really expand my capabilities in regards to being able to show the project plan, baselines, etc without actually requiring a user to download project. This is especially important because of the fact that project can really be a scary big thing on behalf of an estimated all users upon first beginning to utilize it. It also saves lots of cost as well as some space on all of the developer as well as related project personnel. Specification as well as Project Plan Sign Offs All stakeholders sign off on the functional, technical, as well as design specifications as well as the project plans. Everyone must be in agreement from the customers to the teams that shall be implementing it. This saves time down the road, as it’s more costly to manufacture changes to projects further into the project as well as ensures that all involved parties have been included as well as have taken responsibility on behalf of the solution. Personal Note: If there's trouble making the technical specification an estimated all of the time it is because of the fact that the functional specification as well as requirements have not been fully identified. If the design specification has lots of trouble then it’s probably the functional or technical specification that might be at the root of these issues. Development The development phase is fairly straight forward. The technical specification has broken down the technical details. The design specification has broken down the look as well as feel. The development plan has broken down the tasks as well as responsibilities. With all of those in place this is a smooth as well as easily managed phase of the project. It also has HIGH visibility of where things stand because of the fact that you can at all times compare against the development plan, technical spec as well as visual designs. Personal Note: Standards are a wonderful thing but continue to evaluate them to ensure that they remain current, relevant, as well as useful. Keep things structured if possible as this helps you retain estimates more accurate. However do not crush your teams with not possible to meet standards. These provide no benefit as well as detract from the important of standards. Make sure all goals as well as standards are attainable as well as have clear indication of why they assist developers as well as team members. Security Testing One thing that I have seen over the past few years is a new more specific form of testing on behalf of security. In today’s world security is becoming more as well as more specialized as well as more as well as more important. To this end it might manufacture sense to have a security team perform security tests, provide input on potential vulnerabilities, as well as often elaborate on ways to improve security on behalf of the code, application or system. Unit Testing as well as QA Testing There is unit testing as well as there's Quality Assurance testing. These are totally different things. In unit testing you shall test individual components, as well as then STILL in unit testing you shall test things integrated with one another often in a SIT environment. When all of this testing is completed as well as everything looks perfectly solid you transfer it to QA on behalf of testing. But only once you have fully tested the components. QA shall evaluate whether it matches the visual designs, as well as the functional specification. In some cases also the technical specification. Their job is more to just assure that the quality is there as well as come up with tests that the development team would not have thought of. Unexpected user inputs, or ways in which the user can utilize the system (still using the functional specification as a guideline) that maybe the development team missed. Personal Note: It is important to have a SIT (integrated testing area on behalf of all of the individual modules as well as components) environment on behalf of development as well as a seperate QA environment. Keep in mind that all these environments should match as best as possible the client’s environment to avoid environmental issues as well as troubleshooting that might be needed down the road. Deployment Documentation Before you deploy anything anywhere it should be clearly documented what you shall do, what performance as well as outage’s it could result in, as well as how the changes you manufacture can be undone. Along with all of this you should also have any help documentation, user manuals, administrator manuals, as well as other documentation that is produced in your project complete or very clearly defined before implementing any solution on a client’s environment. Lastly, document exactly what you do in that environment so that you can diagnose issues, or protect yourself from being blamed on behalf of unrelated issues. UAT Testing User Acceptance Testing is very important. This is where users review the solution in their posses environment as well as ensure that their expectations have been met as well as that it is a usable beneficial system. Earlier in the plan it was important to note that any communication as well as training should be clearly identified. It is also important to note that if at all possible preliminary training at least should be done before UAT. This shall ensure that your resources at UAT are not teaching people how to utilize the system as much as ensuring it meets or exceeds all of their expectations. Personal Note: For projects where the client doesn’t have the money or interest in training I ordinarily expand the UAT cycle to account on behalf of the fact I (or my team) shall also be training while performing the user testing. UAT Fix as well as Testing Cycles Taking any exceptions from UAT as well as ensuring that they are fixed as well as fully tested as well as then if needed ensure that the user has accepted the changes as well before moving on to the ultimate deployment. These cycles can often go back as well as forth more than once subject to how good communication with the client has been, how well client expectations have been managed, as well as how accurate the initial specifications as well as plans were. Final Deployment Your last deployment (aside from updates as well as new releases). This follows the same documentation rules as before. Communication as well as Training This is the full training, as well as communication phase. Often this could be workshops, webcasts, training sessions, assisting the organization with posters as well as improving internal user acceptance or user adoption etc etc. Support as well as Feedback SLA’s might contain what your support particulars are. Often this could be fixes, warrantees, upgrades, or even reside support. It really depends on what you identified with the client. I also like to ensure that feedback is gained from the client. This provides a wonderful opportunity to create business references, case studies or other great marketing tools because of the fact that the solution is new, exciting, as well as in (hopefully) an estimated all cases the client is very happy as well as satisfied. Hope this helps someone or stirs some ideas on behalf of how to better manage your project through it’s phases, Richard Harbridge        Thu, 09 Oct 2008 15:30:31 -0400 gircrazyp