Jane's Technical Stuff
Archives
May 2002March 2003
May 2003
July 2003
August 2003
June 2005
July 2005
August 2005
December 2005
January 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
July 2008
August 2008
September 2008
Monday, July 21, 2008
Post-Implementation/Post-Project Reviews
In my almost 15 years of development, I've found little more beneficial than a well run Post-Implementation Review meeting. I find them a great to way to learn, improve and ensure that the next project goes more smoothly than the one before.
It is a meeting held at the end of a project at which people who have contributed to the project as a whole get an opportunity to discuss the highs and lows of the project.
My preparation normally involves thinking back over the course of the project and thinking about:
The most recent one I attended was run in the order of the project, so feedback was made first against the Sales process, then the Analysis process etc. This worked pretty well, but did mean that the last few stages of the project were rushed to ensure that the meeting finished on time. Alternatives include asking the "What went well?", "What didn't go well?" questions of every person in the room. This ensures that everyone gets their say but does involve preparation on behalf of every attendee (no bad thing).
For me, the ideal meeting should include everyone who has been involved with the project, from start to finish - in some cases this could be a lot of people but every function should be represented - so definitely Sales, Analysts, Project Managers, Developers, Support and Systems. Every person should have an equal opportunity to speak.
Usually, after the project has gone live and been handed over into a support phase. In some cases a project can last too long, and if the project is scheduled to take more than 6 months, its probably worth having 6 monthly review meetings to ensure that key learnings aren't forgotten, or that subsequent projects can learn and improve quickly. These shouldn't replace the Post Implementation Review but should supplement it.
The final part of the meeting should be a quick review of the "What went well?" items, and of the "Key learnings". Someone should be tasked with producing a document which should then be circulated outlining the key learnings from the project, and also the highs - the lows should be kept within the team and learnt from but not circulated - it shouldn't be a shaming exercise but should be a great motivator. Any individuals charged with process review, or implementing changes to current/ongoing projects should be informed of the key learnings to ensure these learnings are escalated and implemented as quickly as possible.
What is a Post-Implementation/Post-Project Review?
It is a meeting held at the end of a project at which people who have contributed to the project as a whole get an opportunity to discuss the highs and lows of the project.
My preparation normally involves thinking back over the course of the project and thinking about:
- what went well?
- what didn't go so well?
- what we could do better next time and what lessons we can learn
- How well the project was analysed and specified
- how well the project was managed
- how well the testing phase went - bugs found in testing vs UAT vs post-live
- how well the handover to support went
- how well the original time estimates reflected reality
- how well specified the infrastructure was - were the original estimates on page impressions etc valid
The most recent one I attended was run in the order of the project, so feedback was made first against the Sales process, then the Analysis process etc. This worked pretty well, but did mean that the last few stages of the project were rushed to ensure that the meeting finished on time. Alternatives include asking the "What went well?", "What didn't go well?" questions of every person in the room. This ensures that everyone gets their say but does involve preparation on behalf of every attendee (no bad thing).
Who should be there?
For me, the ideal meeting should include everyone who has been involved with the project, from start to finish - in some cases this could be a lot of people but every function should be represented - so definitely Sales, Analysts, Project Managers, Developers, Support and Systems. Every person should have an equal opportunity to speak.
When should it happen?
Usually, after the project has gone live and been handed over into a support phase. In some cases a project can last too long, and if the project is scheduled to take more than 6 months, its probably worth having 6 monthly review meetings to ensure that key learnings aren't forgotten, or that subsequent projects can learn and improve quickly. These shouldn't replace the Post Implementation Review but should supplement it.
What should happen afterwards?
The final part of the meeting should be a quick review of the "What went well?" items, and of the "Key learnings". Someone should be tasked with producing a document which should then be circulated outlining the key learnings from the project, and also the highs - the lows should be kept within the team and learnt from but not circulated - it shouldn't be a shaming exercise but should be a great motivator. Any individuals charged with process review, or implementing changes to current/ongoing projects should be informed of the key learnings to ensure these learnings are escalated and implemented as quickly as possible.
// posted by Jane @ 7:31 PM 
Comments:
Tuesday, September 18, 2007
My first Madgex project live
The first project I worked on at Madgex went live last week. It is a customisation on the Origin Job board, and is a series of 8 Dutch job sites working off one database, one Admin site and one Recruiter access site. New job seeker sites are due to be added early next year, so it has been designed to work with 20 - 30 different job sites.
I moved on to a new project before the sites went live so Mike picked up the project and saw it through to launch. Thanks Mike!
The sites are:
As with all projects it had its challenges, but as this was my first localised project, it also had its learning opportunities. Despite the clients only wanting the sites to work in Dutch, I decided to strip all of the static text into resources files and allow the opportunity to display any of the 3 sites (job seeker, recruiter services or admin) in either English or Dutch. This was primarily to allow for easier development and support. There is an entry in the Web.config file to allow the culture to be defined. So far, it has worked pretty well, except that to update the resources file the web sites all need to be stopped to prevent them from locking the file. However, updates are rare so this isn't a big problem in the grand scheme of things.
One of the great delights about Madgex is the way that the design works. We have creative designers who do the pretty bits and we also have a team of HTML developers who do HTML and CSS (and some javascript) meaning that as a developer I integrate the HTML with the objects and get it all functioning. So, instead of spending hours doing cross browser checking or trying to work out how to get a certain effect to happen, I have a designated HTML developer who does this for me and tells me what I've done wrong, leaving me to get on with the functionality. Perfect!
All in all a succesful project which involved great team work, and great people. Looking forward to the next one.
I moved on to a new project before the sites went live so Mike picked up the project and saw it through to launch. Thanks Mike!
The sites are:
- Elsevier.nl - Vacatures
- FEM Business
- ElsevierFiscaal.nl
- Overheidsmanagement.nl
- P&Oactueel
- ControllersMagazine.nl
- Nursing
- accountancyvandaag.nl
As with all projects it had its challenges, but as this was my first localised project, it also had its learning opportunities. Despite the clients only wanting the sites to work in Dutch, I decided to strip all of the static text into resources files and allow the opportunity to display any of the 3 sites (job seeker, recruiter services or admin) in either English or Dutch. This was primarily to allow for easier development and support. There is an entry in the Web.config file to allow the culture to be defined. So far, it has worked pretty well, except that to update the resources file the web sites all need to be stopped to prevent them from locking the file. However, updates are rare so this isn't a big problem in the grand scheme of things.
One of the great delights about Madgex is the way that the design works. We have creative designers who do the pretty bits and we also have a team of HTML developers who do HTML and CSS (and some javascript) meaning that as a developer I integrate the HTML with the objects and get it all functioning. So, instead of spending hours doing cross browser checking or trying to work out how to get a certain effect to happen, I have a designated HTML developer who does this for me and tells me what I've done wrong, leaving me to get on with the functionality. Perfect!
All in all a succesful project which involved great team work, and great people. Looking forward to the next one.
// posted by Jane @ 8:50 PM
Comments:
