Friday 27 November 2015

Project Team Selection

How big should your project team be? Too small it won’t be big enough to share the burden or represent all the constituencies or disciplines of the business. Too big it will be difficult to organise and manage. Also individual ownership, engagement, commitment will be too diffuse. Of course it also depends on the size of project. Is the deployment thirty sites, with 5000 users over 6 continents or a single site implementation with just a few users?

How representative should the project team be? It ought to represent the many departments or areas of the business. It should also have a blend of disciplines like design, finance, operations, IT etc. It also needs a blend of people with both creative ad analytical flair.  

Other dimensions contributing to a project team’s effectiveness observed on my travels are:
Members must have knowledge of the business
Members must have process knowledge
Members should be free and able to participate, unencumbered by their day job
Avoid department, team or senior operational managers

Business Knowledge
Whilst this is not an argument against recruiting new employees to the project team it is a cautionary note regarding corporate culture. Organisations settle into a way of doing things a so called, ‘custom and practice’ so any new comers had better get to know about the ‘corporate way’ or ‘culture’ or risk upsetting quite a few people. It is sometimes necessary to break established norms to achieve real change, but you have to take people along with you or the change will be impermanent or transient. People who have worked in an organisation for more than a two years have by osmosis absorbed organisations way of doing things.  Moreover they will be able to identify colleagues who find change threatening and those who are open to change. This is useful knowledge when it becomes time to ‘sell’ the project.

Process Knowledge
Project Team members must have knowledge of the business processes for the constituencies they represent. Quite often project team members will be representing more than one work based team or department. Ideally they should have worked in the teams or the departments they represent and have had hands on experience of the processes within those teams and departments. This task centric competence usually establishes the project team member’s legitimacy and credibility in the eyes of the teams and departments they represent.

Ability to Participate
Project team members should have the ability to participate in the project team proceedings which means that they will be able to commit a substantial amount of their working time 80% or even be full time on the project.

Avoid Managers
Managers have a day job and they are judged by the results of their efforts toward the goals of their day job. Experience suggest that managers do not make good project team members because they angst about the day job and are constantly being pulled back to it. It is better to appoint the managers first lieutenant or right hand person to the project team. This has a number of advantages:

                They don’t have the same conflict between the day job and the project. 
                They are usually hands on and know the processes well.
                They don’t usually ‘own’ the existing processes so are more open to challenging them
                They are keen to learn and develop their careers
                The project is great way to train the next generation of managers

My recommendation to avoid managers doesn’t mean the managers are not involved in the project, they are but at a strategic level as business decision makers, more of this in a later….

The following article and book gives other insights into building project teams:
Nobody’s Perfect but a team can be, Antony Jay Observer Magazine, 20th April 1980, 8 pages:  
Management Teams: Why they succeed or fail, R Meredith Belbin, Butterworth- Heinemann, London, 1996, 192 pages, ISBN-10: 0750626763, ISBN-13: 978-0750626767

Happy Implementing!

Tuesday 10 November 2015

Book Review: Developing teams through project based learning

Book Review: Developing teams through project based learning
Jean Atkinson, Gower Publications, Aldershot, 2001, 152 Pages, 8 Chapters + Appendices, ISBN-10: 05660 83671, ISBN-13: 978 05660 83679
 
Available from:
 
 
 
I find the dynamics of project teams fascinating. To work with a project team that communicates and treats each other with respect, yet challenges each other is great! This book isn’t really about building and developing a winning project team. It is about developing people through projects. However I see it as a two way street and the chapters in this book are just as valuable in engendering project team wellbeing and effectiveness as they are for developing individuals. Learning, dealing with and overcoming difficult situations, is for me, life affirming. My experience over many years and projects is that very few businesses ‘back-fill’ the project team members jobs to allow them to concentrate on the project. Therefore most project team members have two jobs their ‘day job’ and their ‘project job’. The book covers recognising and dealing with stress. Having two jobs or even looking back at the day job is a recipe for stress and anxiety. The book looks at both soft and hard skills which project team members will need to acquire to become effective project team players. The book is short so it doesn’t have in depth coverage of topics. Nevertheless for a project manager there is enough information, supported by templates to stimulate thoughts and actions. I really like the book’s brevity and bitesize approach to project team dynamics. Well worth a read.
 
Happy implementing!

Leverage your project manager’s experience when resourcing

CRM and ERP projects require a significant number of people with specialist skills. It's great if you have the time to develop these skills in house but it isn’t always possible and sometimes it is unnecessary or undesirable. Unnecessary because they will only be used during the project. Undesirable because it doesn’t fit in with you long term strategy.

The types of skill you may wish to buy in include:
Infrastructure specialists
Installation and configuration specialists
Migration specialist
Application consultants
Business analysts
Software developers
Testers
Test managers
Trainers
Etc.

So you decide to resource from the contract market.  Before you start resourcing the skills for your project. Hire a project manager and leverage their experience. They know which developers deliver and which ones to avoid. They have made their mistakes on earlier projects have the scars and more importantly the experience to help you resource the team that is right for you and your project.  Every project manager has an address book of good people who they know they can trust to deliver the project.

Happy Implementing!

Sunday 1 November 2015

Book Review: Project Management for Data Conversions and Data Migrations

 
Book Review: Project Management for Data Conversions and Data Migrations
A data conversion methodology and to converting data for mission critical applications
Charles R Scott, Author House, Bloomington Indiana, 2004, 99 Pages, 18 Chapters + Appendices, ISBN10: 14184 51265, ISBN13: 878 14184 52162
 
Available from:

 

 
  
This book provides a great route map and checklist for data migration. I regularly use it as a reference when planning new projects to ensure I haven’t missed anything. The chapters are broken down into work packages familiar to us project managers. To me it is designed as a reference source rather than a book you would pick up and read. Don’t be lulled by the regular and consistent structure of each work package in the book, some are more difficult and contain more risk than others. I always start the data migration work-stream within a few days of project inception. Experience, over many years, has taught me that it is always a long lead time work package. The migrated data needs to be ready for transactional testing when user acceptance is taking place. Another cautionary note is on the subject of data cleansing, the book has a chapter on the topic. On the page it appears simple but experience has imparted a wariness of this work package, nevertheless the book covers the data cleansing bases. The book falls short in one area, not content, but print quality the diagrams are not prominently printed with insufficient font and line weight or thickness to be clear. Also the diagrams would be better printed in landscape rather than portrait format. In the appendices the author offers some useful data migration project management templates and a skeleton work breakdown structure. A useful addition to the project manager’s reference bookshelf.
Happy implementing!

Functional specifications are incomplete without test plans!

There is a problem, a modification is suggested to overcome the problem. Stakeholders become bound up in tide of enthusiasm regarding the suitability and elegance of the modification, relieved the problem is solved. But is it? It is easy to lose sight of ensuring that time is not wasted in development and testing by having to re-develop and re-test because the functional and technical specification were not subjected to proper scrutiny and diligence in the rush to solve the problem. Does this situation sound familiar?   

The synopsis of the change is written outlining, functionality, benefits, costs and risks. The change is approved in principle. A detailed functional and technical specification is prepared. At this point are the specifications ready for review, approval and development? Only if the specifications includes a test plan.

Insisting on a test plan before the modification is approved for development will inform and challenge the functional and technical specifications ensuring they are complete and robust. The stipulation that a test plan must be included becomes moderating influence on the modification requestors forcing them to think through the modification before submitting it for approval. It also immediately raises the quality bar on the specification. As a starting point the user who requested the modification should be invited to explain how they would go about testing the functionality of the modification. This basic test premise should be then developed into a battery of test cases covering unit, edge or envelope and integration testing.

 The development of a comprehensive test plan for the modification is best done in a team setting where business analysts, users and developers can build on and challenge each other’s ideas. Time spent deriving the test plans prior to final submission and approval will pay dividends in ensuring the veracity of both the functional and technical specifications saving time later in development, unit and user acceptance testing. Once the test cases have been developed like any other project document they should be subject to peer review. This is best done again in a project team setting, often suited to a walkthrough type meeting supported by an algorithmic diagram, a few days after the test cases were originally documented.  In most cases a second walkthrough review separated by a few days proves beneficial in ensuring quality, the old adage measure twice cut once comes to mind.

Happy implementing