Tips for leading global project teams successfully

Being involved in supporting and leading multi-location / multi-cultural teams there are some general guidelines I follow (more or less). The list turned out to be quite big:

* Find some time for everyone personally. Use the phone or face to face (no e-mail, or chat)

* Start each project with big bang. Team members and stakeholders must get to know and talk to each other

* Use weekly catch-up meeting. E.g. ‘scrum of scrums’ and involve relevant team-members / stakeholders

* Use technology to bring people together (ONLY as a last resort). Use video, not only voice, screen sharing and chat

* Share a common project management platform. E.g. Jira, Basecamp

* Encourage different team members to talk to each other – over the phone or in person. The e-mail communication is to be used only as a back-up channel for the requests

* Have a clear vision and communicate it openly (long & short term)

* Set clear goals

* Have clear responsibilities (could change in long term)

* Don’t stop supporting the coordination between the teams even if it goes really well

* Encourage open communication and listen to the feedback

* Talk to the clients and share the feedback among the teams

* Trust is everything – build trust not only within the same team but also support building trust within members of different teams

* Encourage cooperation

* Friendly competitiveness is also beneficial

* Keep focus on what is really important (never stop prioritizing and get rid of the ‘non-essential’ stuff)

* Celebrate and reveal each success. Spread the successful stories

* Be a good example

* Balance your time well, between stakeholders and team members

* Share and do some of the work. Fill some gaps and support your teams

* Be enthusiastic and positive

* Focus on effectiveness and delivery

* Don’t waste your and your people’s time. Avoid pointless meetings. Be quick and to the point

* Self-management is blessing but don’t be afraid to manage when needed or the teams are in doubt

* Don't just follow the traditions and the rules set. Innovate together with the folks

* Be a human being – it’s not only work. Offer empathy and sympathy when needed


My general vision is to elaborate more on some of those and provide examples in my future posts.

PRINCE2 Knowledge Train materials review

Those of you interested in project management probably are aware of the scarcity of free information regarding PRINCE2. Probably it’s due to the copyright claims (e.g. PRINCE2 manual is not distributed freely) and courses/training industry is attracting participants by not revealing a lot of the course content and materials, anyway.

Recently I was asked to review the PRINCE2 items provided by Knowledge Train. As a practitioner I was curious to browse through the free materials on their website and evaluate the result of their effort in summarising PRINCE2 in a couple of e-books. Surprisingly, everything I managed to read there is very useful. Not only the principles, the themes and the processes are explained well, the visuals (diagrams) are simply beautiful too. For example just looking at the ‘Starting-up a project visual’ makes it perfectly clear what is needed, in order to trigger the project, appoint people, why do you need a business case and what a lessons log is.

I remember when I first read the PRINCE2 manual – it took roughly two months to understand everything into details. And if somebody is up to the challenge of becoming a practitioner most probably the manual is still a must but why not starting with something simpler and easier to read. The e-books provided at the link below would definitely give you some overview and maybe even help decide if PRINCE2 is your ‘thing’ and if it would be useful for your organization and projects.

https://www.knowledgetrain.co.uk/prince2-ebooks.php

No Delays – transforming GPs and patients relationship

No Delays is the most ambitious and innovative product I had the pleasure to manage in 2013. A series of projects were completed successfully, leading to a great product developed and being piloted used in Scotland with the aim to transform the relationship between GPs, consultants and patients.

The main idea behind the product is providing GPs with the extraordinary ability to prescribe “electronic package” to patients with long-term conditions. The most obvious benefits are:
- Providing patients with high-quality but easy to understand medical presentation/s.
- Access to personalised information and next steps actions.
- Empowering the patients to take control and take the best possible care.
- Supporting patients digitally.
- Reduction in the outpatient attendance
- Improving the collaboration between GPs and specialists.

SCRUM was used to facilitate the work, breaking down the epic requirements into user stories and acceptance criteria and organising the delivery into short two-week sprints. On top of that more traditional (PRINCE2) project management happened and the usually expected documentation (mandate, business case, plan/budget/resourcing, etc...) was elaborated.

Though, the document which got most of the focus was the product backlog containing all the items we might ever do for the product. Closer to a sprint review date we had a backlog grooming sessions to break down, clarify and plan the next sprint items. On the sprint review itself the items were further clarified, estimated, further prioritised and the lucky ones found their spot into the sprint backlog.

The team varied throughout the different projects and usually consisted of UX expert, design specialist, 2 back-end developers, 1 front-end developer and a content producer. The head of the product design was the designated product owner and I acted as scrum master, QA, content producer and covered any other roles when needed. On top of Scrum I managed the stakeholders’ relationship assisting the product owner with gathering requirements and adding new items to the backlog.

The total budget for all No Delays projects in 2013 was close to half a million GBP. We developed two prototypes, organised and delivered the content for 9 conditions, did some usability testing and ended up with an MVP developed in less than 2 months. The last project had a couple of sprints to continue with the incremental development. The flexibility provided by Scrum was invaluable allowing us to adapt and improve the product on a two-week basis period and satisfy the stakeholders by constantly exceeding their expectations.

The product site: nodelays.co.uk

Birmingham Children’s Hospital website / mobile project

Digital Life Sciences / Illumina Digital was commissioned to develop and deliver new look and features for Birmingham Children’s Hospital website and to enhance the experience for its mobile users. The adaptive design will help thousands of visitors who browse the website using their mobile devices. As a part of the project a news section was delivered for both desktop and mobile users too.

Scope

- Home page redesign (desktop)
- Completely new mobile home page
- Adaptive design for two widths – desktop and mobile friendly
- News section as a part of the website
- Homepage slideshow
- Couple of other improvements

Team

I managed a team of designer, frontend coder, backend developer and the client provided a product owner who also did external Q/A, and sign-off.

Methodology and how the project was delivered

It was decided to go fully Agile and use SCRUM with short (7 days sprints) – total of 5 sprints was agreed.  A backlog with 20 items was produced and prioritised. The product owner re-prioritised the items after every sprint ending on a sprint planning meeting.  We managed to deliver slightly ahead of the schedule and the 5th sprint was only used for final deployment. The daily scrums with the product owner (over phone) proved to be efficient in reporting, testing and signing off items quickly. As it is a Drupal website we had to create several new content types and functionalities as well as modifying the existing template.

Major issues/challenges

- Producing an adaptive design for all the mobile phones proved to be a difficult task. We decided to focus on the latest iOS and Android devices. Some of the javascript galleries still won’t work an all devices (especially very old ones).
- At several points we were running ahead of schedule and had to pull out/agree on items from the backlog.
- Had to cover a frontend developer for a few days. It was good that the backend developer and I managed to cover.
- The deployment was tricky as it is a major website.

Delivered result

The home page and the slideshow could be reviewed at:
https://www.bch.nhs.uk/

The news section is located and could be seen here:
https://www.bch.nhs.uk/news

The mobile adaptive design could be accessed from mobile phones. Here is a sample picture of it:

PRINCE2 documents / management products

I. Project trigger (by the Corporate/Programme)

- Mandate
This is the initial document to trigger the project. The minimum that it should contain is:
Reasons why the project is needed and expected change
The tolerance in terms of what is the maximum resources to be spend
Roles and responsibilities – at least the Executive and the Project manager (preferably) should be appointed

II. Starting up Project (SU) / pre-project

- Outline business case
The basic outline of a Business case. At this point it will contain the reasons, the options and the basic costs/schedule
- Project team structure and roles description
Roles and responsibilities of the team members and the appointed persons (by the Exec)
- Project definition
The scope of the project
- Project product description
Describes what is expected as a final product of the project (characteristics)
- Project approach
How the project product will be created /achieved
- Project brief
Consists of all the other documents so far in SU (does not include stage plan or the logs)
- Stage plan
-lans the initiation stage – if the Project board authorizes the initiation
- Daily log
Servers like a journal for the Project manager – all notes, reminders, issues should be in it (handled informally)
- Lessons log
Any useful lessons for this and future project should be stored there

III. Initiating Project (IP) / Initiation stage

- Full business case
The full business case should contain the entire business justification: benefits, costs, timescale, major risks
- Benefits review plan
A plan containing when, who, how and where the benefits will be measured both before and after the end of the project
- Project plan
(part of the Business case) The plan should cover all the stages after the IP and should contain costs/timeframe/responsible team managers, etc
- Project controls
The controls required to ensure the project runs properly
- Risk register
Details of all the risks and the mitigation actions
- Issues register
Issues that are handled formally
- Quality register
Individual quality check or activities
- Risk management strategy
How the risks are managed in the project
- Quality management strategy
How the project will ensure the product is “fit for purpose”
- Configuration management strategy
How the project will manage the configuration and the change requests
- Communication management strategy
How the communication will flow in the project. Stakeholders analysis and the needed comms
- Project initiation documentation (PID)
It expands the project brief and contains the full Business case, the strategies, the controls and the Project plan

IV. Controlling delivery stages (CS)

Controlling a stage
- Work package
Used by the Team manager (and created by the Project manager). The work package contains the entire information the team manager needs to deliver the specialist products (plan, budget, milestones, scope, techniques, comms channels, etc...)
- Stage plan (updated)
The main plan updated with actual details
- Highlight report
A report from the Project manager to the Project board regarding the current stage progress
- Issue report
Issue handled formally
- Exception report
If the stage is about to breach the foreseen and agreed tolerance

Managing product delivery (MP)
- Work package
Used by the Team manager in MP
- Team plan
Optional – created by the Team manager to meet supplier standards
- Checkpoint report
Report sent by the Team manager to the Project manager with the current progress of the Work package
- Delivery notification
When the specialist products are created/produced
- Specialist products
The products/items that need to be created and tested before being delivered

Managing a stage boundary (SB)
- Stage plan
Full plan for the activities and the results in the stage
- Exception plan
To replace stage plan if the stage plan goes off the agreed tolerance
- Project initiation documentation (PID)
Modifying and updating the PID where necessary
- End stage report
Report to the Project board accompanying the next stage plan and the updated PID

V. Closing a project (CP) / Final delivery stage

- Follow on actions
The follow-up documentation when the project is signed off and the final delivered product/s change ownership
- End project report
Final project report to the Project board consists of assessment how the project was executed against the PID and the Business case
- Lessons report
The good practices and the fields of improvement (mistakes) passed to the Project board and then to the Corporate/Programme
- Closure notification
To the Project board to be used to close the project to the Corporate/Programme
- Benefits review plan
Should be updated how and when and by whom the benefits will be evaluated after the project is completed. Post project reviews should be carried on by the Corporate/Programme

Digital/Web project management process

Whenever you are about to start new digital project you might wonder what exactly the process should look like, or what team members you need to engage? In this article I will describe the universal process and the most common team members involved.

I. Digital/Web project management process

1. Idea/requirements and rough estimation

Before the start of the project, there is the idea. It might be a customer’s idea or the product owner’s idea. The idea is then transformed into requirements and estimation in time, money and other resources is provided based on the requirements.

2. Signed contract or signed project brief/initiation document

If the customer or the product owner (stakeholders) agrees with the estimation you are going to have a contract or project initiation document signed.

3. Inception meeting

Inception meeting (with all project team members) purpose is not only to introduce the team members to each other. The project manager should organize the inception meeting with prepared project plan to discuss and approve by the other team members. Everybody in the team should know “what” and “when” is about to happen (different stages) and also “who” is responsible for every specific task.

4. Detailed requirements and specifications

The project manager and the product owner/customer should sit together and go through the requirements and get into details to clarify any queries. Clarified and detailed requirements are important so the transformation to well written specifications could happen.

5. Mock-up and design

The mock-up is just the outline of the visual structure of any design or feature. If you are going to manage a huge web project – mock-ups are mandatory to save a lot of time and resources. Once there is an agreement over the mock-ups the designers could finish the actual design (colors, buttons, backgrounds, fonts, fancy items, etc...)

6. Front-end coding

Once the design is done it needs to be turned into html/css code. This is what the front-end coders do. Also they add different features driven by javascript or other codes.

7. Beta development / back-end coding

The beta development could start even before the design. The back-end system is the backbone of your digital/web project. Every piece of data you see on the frontend is coming from database/code and the back-end developers ensure that the back-end system works without any flaws. Any critical and major defects/bugs should be fixed during beta revisions/development.

8. Final revisions and polishing

This is the stage where you need to involve the product owner a lot to ensure they/he/she is satisfied with the results. Any smaller issues should be addressed before the digital/web project is about to go live.

9. Going live and demo meeting

When you manage large digital/web projects it is important to allocate enough time and resources for the “going live” stage. Sometimes you need to ensure the hardware is going to stably sustain the traffic and the load and work closely with the system administrators too. It is always good to have a demo meeting in the end of every project, where the project manager, the product owner and/or the team members present the project’s features.

10. Maintenance and Support

These should be ongoing. Any future developments are better to be managed as separate projects and not just under support and maintenance.

II. The digital/web project team members

Below are the possible team members you are going to involve into a digital/web project.

1. Sales person

... or the sales team. They are responsible to gather the initial requirements (from the customer), to ask for rough estimation (from the design/development team) and have the contract between the customer and the company signed off. If the project is internal – the project manager is responsible for these steps (initial requirements, rough estimation, project initiation document signed).

2. Customer / Stakeholders / Management team / Product owner

This is the person (or the party) responsible to authorize the project, provide the requirements, and sign off and accept the delivered project. Also this is the person (the party) to address when the idea/requirement needs clarification.

3. Project manager

The project manager liaises with the rest of the team members and is responsible for the ultimate project delivery. Also the project manager is responsible for the entire project’s documentation – project plan, check list, gantt chart, specifications, project history, etc...

4. Design team

The team (or the person) responsible for the mock-up and the design of the project.

5. Front-end development team

The team responsible for html/css/javascripts, etc...

6. Development team

The team responsible for the back-end development, the software architecture and the backbone of the software project.

7. System administrators

The system administrators provide the hardware and the software support, to run the entire project. They also ensure that the system will have enough capacity to sustain the load.

8. Q/A team

Quality assurance is an important aspect through the entire project delivery process. The Q/A person matches the software with the specifications and ensures there are no defects and differences. If there is no dedicated Q/A team member, the project manager is responsible for stable Q/A.

Project managing classifieds section for Automedia.bg

I have managed this project for three months – from January 2012 until the end of March 2012. Automedia.bg is the largest Auto Media web site in Bulgaria. The web portal consists of articles, categories, galleries, forum and different kind of videos, polls, test drives, and other features. What we missed by the end of 2011 was a section with classifieds where people could browse, look and buy different auto, motor and truck vehicles. In the Automedia strategy – we all (I, OPS dir, CEO and the other directors) approved to initiate, develop and complete this project by the end of the first quarter of 2012. And we were successful - the section is up and running and you could visit it here.

Project scope

The project scope was to: develop classifieds section integrated into Automedia.
The following features had to be implemented:
- Classifieds listings
- Classifieds search – basic and advanced search
- Classifieds pages
- Gallery with pictures for each ad
- Different ad codes to display adverts
- Additional content boxes to be implemented in Automedia

Initiating project phase and design

I and the OPS director negotiated with a partner from Bulgaria to receive the classifieds from their web portal. Also we were successful to negotiate their development team to build the section. On IBG end – we needed to do the designs and the front-end coding, before sending for development. And as usual we started with mock-up of the pages and followed up with a design. I was managing the whole process and was responsible to manage our designers/developers and to communicate with our partners. The design was done but we did not have any available front-end developers so I and the OPS director decided to outsource the front end coding. It was done really well and then I moved the project to our partners do develop it on their own server. I sent them a package containing – the design, the front-end code and specifications to start working.

Development of the section

We have arranged just one meeting to clarify the project features at this point and just after 4 weeks the beta site was done. It was up to me to provide revisions and it took another week to fix some issues before we were ready for a launch. As planned, we needed our system administrators to connect the sub-domain name with the section on the sever of our partners. It took a day to configure this but we managed to meet the deadline and we launched the classifieds section by 27th of March 2012. It was a great success and drove 25% more traffic to Automedia. The visitors found the section very useful and were grateful for it.

Project managing a web portal for Euro 2012

There are just two days to the final Euro 2012 match between Italy and Spain, after the beautiful victory Italy claimed against Germany yesterday. As a person who took part in the Euro 2012 online presence for the Bulgarian market, I am going to describe a very nice project I managed and completed about two months ago. It was a micro website for Euro 2012, developed for the largest Bulgarian football portal – gol.bg (part of IBG group). The website is still there – so feel free to visit it at: www.gol.bg/euro2012/

Project scope

The project scope was to create an Euro 2012 micro website in Gol.bg
The micro website should have had the following sections:
- Main page with recent news, articles, games forecasts, analysis, ads, etc…
- Special sections with forecast, analysis and lifestyle news
- Section about the groups and the teams
- Section about all Euro championships - the history
- Section about the cities and the stadiums
- Section containing calendar of the matches
- Gallery section

My team consisted of internal UX gurus and designers, internal media team and external web development company. I was responsible to project manage the execution and the delivery of the project. We started doing the mock-up and the design of the pages. I provided design specifications – regarding the sections we needed and the the type of content the designers needed to put in every section. Our internal designers did a great job of selecting the most relevant color scheme and to provide great maps, pictures and photos of the stadiums, national teams, national flags, various logos, etc… After that - the design was approved by the Ops director and the company management.

It was time for me to move the project, along with the development specifications to the external web development team. They needed to do the front end coding and the development of the micro web site. They did a great job of doing the frontend coding in less than a week and to deliver the first beta site in about two weeks. I am not going to bore you with my checklist and project plan, but just want to mention that everything went really smoothly and according to my plan. After the beta site was completed I and Gol.bg media team inspected it and returned several revisions. After they were implemented it took some time before the media team was able to fill all the needed content. When this was done – I presented the project to our managers to get the final approval. And in the second week of May 2012 – our Euro 2012 micro website went live. More than 50 000 unique users are visiting it every day and the feedback we receive is really great.

Mobile version of Dnes.bg

I am very proud that I and my team were able to complete this huge project just 2 weeks before I left Investor.bg Group (IBG). It was a real challenge to project manage the idea, the design and the development of entire new mobile web site for the largest news portal in Bulgaria – Dnes.bg
Today, the mobile website is up and running, so please feel free to visit it at: m.dnes.bg

Project scope

- To develop a modern mobile web portal for Dnes.bg
- User friendly and easy to navigate home page
- Article page with various placeholders
- Comments functionality
- Listing pages
- Gallery page with thumbnails
- Horoscopes section
- Currency rates section
- TV and Cinema programmes sections

The main goal of the project was to design, develop and deliver a great mobile web site for the largest news portal in Bulgaria – Dnes.bg

Project team

Lubo – Chairman of the board of directors of IBG
Iana – OPS director (at IBG)
Alex – External UX/Design consultant - https://posteffects.bg/
Emarketing – External Web marketing agency - https://emarketing.bg/
Hristo – External Web developer
Dnes.bg Media team (at IBG)
Simeon – Project manager (at IBG)

The team consisted of IBG members, External UX/Design consultant, External Web developer, External Web design agency. I, Iana and Alex were responsible to elaborate the idea, I was responsible to write project specifications, project roadmap and to communicate with Emarketing and Hristo so they could deliver the final product. Emarketing were responsible to do the mock-up, the design and the front-end coding, and Hristo was responsible to do the development of the web site. Lubo acted as the manager who provided final approvals at the stages and Dnes.bg Media team supported the project once it was published live.

Project resources

Lubo, Iana, Dnes.bg media team and Simeon – employees of IBG
Alex – External consultant – hourly based cost
Emarketing – External/Web marketing agency – design & frontend. Fixed contract
Hristo – external web developer - hourly based cost

Costs:  ~100 000 EUR
Time: ~ 82 working days (4 months)

The costs calculations were done based on the fixed contract with Emarketing, the hourly based payment rate of Alex and Hristo and also the time that the IBG team members spent on the project. The exact number is confidential information, so 100k is just an example number.

The project checklist

Here is the checklist I used to manage the project. I also used project specifications document and my project/task list to write down notes about the project. Also a flowchart containing all the pages and functionalities (and the logic behind them) was created by me. The tasks were broken down using simple waterfall technique. The project roadmap was:
1. I, Iana and Alex discussed the project, the pages and the mock-ups with Emarketing.
2. Emarketing delivered mock-ups for the major pages.
3. We discussed the mock-ups at IBG and provided revisions.
4. Emarketing implemented the revisions and then authorization was granted to proceed with the designs of the pages.
5. Again, the designed pages were revised and approved after that.
6. The frontend coding was done by Emarketing.
7. The project and the project specifications were sent to Hristo for development.
8. The beta site was revised.
9. The site went live – and we (IBG team + Hristo) continued to monitor and maintain it.

After the new mobile site was launched live – we received tremendous amount of positive feedback. Our managers were happy but most importantly the users using the mobile web site were very happy about it. And all the team members were very proud that we managed to deliver such an outstanding product.

Project management checklist

Starting your new project? Executing new strategy plan? Or just managing the implementation of a new feature? In all those cases you are going to need a project management checklist.

Purpose of the project management checklist

The purpose of the project management checklist is to ensure that the project manager and the team members are aware of every detail regarding the project and every specific micro-task. The project manager should be responsible to create, update and manage the checklist. The checklist should clearly answer the following questions:
- What is the roadmap to finish the project?
- Which task should be done before, after or along with each task?
- Who is responsible to develop and do the task?
- What is the due date and the estimated time for each task?
- What is the ultimate due date to deliver the project completely?

You could use project management software like Microsoft Project to help yourself with breaking the project into tasks. Also, a simple Excel spreadsheet could be used to create your checklist.

Good project management checklist

I am providing an example of a checklist I did for one of the projects I managed. Here are several points to pay attention when creating your checklist:
- Prepare the tasks in the traditional waterfall methodology. The tasks that should be implemented first should go on the top of the other tasks.
- There should be an estimated time for every task.
- There also should be a separate field for the due date of every task. This should be the final due date when the task must be completely finished/delivered.
- There should be a responsible person or team (team leader) to deliver the task. You could also put supporting persons there.
- You could use colors to mark any due dates in danger or any due dates that were not met.
- You could leave a note field for every task. This, in no way should keep you out of filling details about the project in your project/task list note field.
- You need to get into details and break the project on relatively small tasks – that’s the purpose of your checklist.
- You need to manage your checklist and even add new tasks when they appear. Also update the project management checklist every time something happens with a related task.

What should you avoid doing in your project management checklist 

- Avoid overcomplicating your project management checklist. Your checklist is there to help you manage the project, not to be additional bureaucratic burden to you.
- Having a responsible person or a team and also getting proper estimates and due dates is the core data in your checklist. Always ensure that those fields are filled in.
- Avoid using your checklist to store very detailed notes regarding particular task. You should be using project management list to store detailed notes about how a particular project is going. It is easier to read and keep track of the notes there.

PRINCE2 project management basics

PRINCE2 project management methodology is a Registered Trade Mark (Crown Copyrighted) of the Office of Government Commerce in the United Kingdom and other countries. Due to this fact I am only going to share some basics of PRINCE2. The following article is not to be considered as a substitute of the official PRINCE2 documents but just to serve as a basic source of information and also to provoke your further interest in PRINCE2. It is highly recommended to purchase additional materials and courses and also to visit the official PRINCE2 site for more information.

PRINCE2 introduction

The Projects in a Controlled Environment is effective and widely used Project Management methodology. It is a structured method and could be incorporated in the management of very huge and expensive projects in different fields. PRINCE2 is also pretty much traditional kind of approach – very structural and the idea is to ensure that the project is broken down into stages and each stage is delivered in terms of scope, cost and due time.

PRINCE2 principles

There are seven basic PRINCE2 principles:
- Business justification at all stages of the project
This is to ensure that the final product delivered by the project should remain valuable at all project stages. The product idea should constantly be checked regarding the environment and if any changes and updates need to be introduced – they should be. It is imperative that the product/change is still important and valuable for the company while the project runs – otherwise the project should be canceled.

- Adjust and learn from experience
It is important for the PRINCE2 team to learn from the experience of the past projects. And it is even more important to adjust the current project management style based on the experience with the current team and project scope.

- Clearly defined roles and responsibilities
It is pretty much self-explanatory. All the roles and responsibilities should be defined in a clear manner.

- Manage by stages
As a traditional project management methodology – PRINCE2 – encourages the project manager and the project board to break the project into stages and implement them one after another (using waterfall method).

- Define management boundaries
For example the project manager could be allowed to do some changes in the scope of the project if they are not going to cost more than certain amount or take more time to be developed than certain time frame.

- Focus on product
The focus should always stay on the product that is supposed to be delivered/achieved by the execution of the project.

- Tune up to the specific project needs
As PRINCE2 methodology could be used to manage small and huge projects – the method could be tuned to fit the current project needs.  Some projects could just incorporate some parts of PRINCE2, for example the project management team structure.

PRINCE2 themes

- The Business Case
The business case is usually the initial idea of product/change that needs to be introduced for the organization. It pretty much answers the question “why should we do this?”

- Organization
The project is always a temporary organization. The sponsoring organization needs to ensure that the proper team members are assigned and available to participate in the project. It should answer the question – “who is involved in the project?”

- Project scope and quality boundaries
The project scope should outline what needs to be delivered in details.

- Planning
The planning is very important part of PRINCE2 project management. All the plans should include the costs, the teams involved and the due dates for all the stages.

- Risk management
Just like in any SWAT analysis - it is important to identify the potential risks/threats for the project and to assess the impact if a particular risk situation happens. There should also be a backup plan “what to do if there is a significant threat to the project”.

- Change management
Although PRINCE2 is a traditional project management method – it allows introduction of “change” in all project stages. The project scope, specifications, team and developments - could all be a subject of change.

- Keep track of the project progress
Following a PRINCE2 project roadmap, the project manager should always be aware of “where is the project now”, “what should be done next” and “what was already done”.

PRINCE2 team

There are four major parties involved in PRINCE2 project management.
- Corporate and Programme management
These are usually the stakeholders or the board of directors of the company. They are responsible for authorizing and funding the project. They also need to delegate the proper management rights to the Project Board.

- Project Board (directing project management)
The company directors – like the CEO, OPS director, Business development director, other directors, senior users of the product, etc... They are responsible for the major project directing and need to authorize the project initiation, the different project stages and to quality check the completed stages in terms of the project scope.

- Project Manager (project management)
The project manager is responsible for the daily project management. The project manager is the liaison between all the involved parties and reports directly to the Project Board.

- Team Manager and The Team (delivering management)
There could be several team managers. Development team manager, design team manager, Q/A team manager, etc... The project manager should delegate the proper development and implementation of particular tasks to the team managers/leaders. The team managers are responsible for the development of the product in terms of costs, due dates and quality assurance.

Project management - Project list

The project/task list is one of the most useful tools a decent project manager is going to need. 
Imagine you are a project manager for external/internal projects and you have more than 20 projects to manage. If you do not have a decent list of projects you soon will be lost and confused. You are going to forget most of the communication done for every single project and put the projects in risk of failure.

So you definitely need a place to store all of your projects information, due dates, progress, task-numbers, etc. And this is why you need this magic tool… the project list.

What information should you put into the project list?

Well, before you get too excited keep in mind that on top of everything else - the project list should be useful and very easy to browse. Imagine a customer is calling you to discuss something about his project. You really need to be able to quickly get to the proper location and information for this particular project. And you definitely do not want to overdo your project list and make it hard to browse.

To start – you need the project’s name for sure. If it is a web project you also need the web site this project is associated with. It is important to have a place to write notes too. And if you are using tasks management software like Jira you need a place to keep record of all Jira task numbers referring to this project. It is also good to have a row with the current phase of the project, and also the date of the latest action – when something was done for the project.

Example of a good project list

Here is an example of the project list I use (click on the picture to enlarge it).

And these are the fields I use:
- Project name – make it clear enough.
- Web site – web site associated with the project. This could really be software name or something else, depending on the type of the project.
- Phase – the current stage of the project.
- Date of last action – should give you a hint when was the last time something happened on that particular project.
- Due date – put your final due date for the completion of the project there.
- Notes/Comments - the most important field!!! Always put a short memo when something happens to the project. Use the format – date/hour and what happened. This way you could always keep track over the project’s actions and parties involved. You could also very easily create reports using the “notes” field.
- Jira N – contains the task number in Jira. It could be used with other task management software as well.

Account Management or how to be a great Account Manager

This article is part of my presentation and training I do for account managers. So let’s dive into the deep immediately.

Account Manager – Primary goals

Your two main primary goals are happy customers and completed customers projects in that particular order. Happy customers are extremely important, because even if you deliver a perfect project when the customer is not happy for any particular reason he/she is not going to form a long-lasting relationship with your company.

Top 5 Account Management rules

- Plan, Plan, Plan.
The account manager needs to plan the execution of the project (even before the first call with the customer). Also he/she needs to plan some back-up scenarios if something goes wrong. This way the account manager ensures the smooth execution of the project.

- Befriend your customer and keep close distance.
Customer who is your friend will collaborate and thus support you to finish the project.

- Create timeline/strategy and also deadlines including the tasks for the customer.
Part of account manager's planning is a checklist/task-list and timeline of the project itself.

- Create the project specifications document and send for development.
Once the account manager has enough information about the project he/she should elaborate the project specifications and send the project into design and/or development stage.

- Keep track of the Project history into Task/Projects list and CRM system.
It is mandatory for the account manager to keep record of the Project history for his/hers reference and also to generate reports for the customer and the superiors.

Top 5 Account Management mistakes

- Do not call back or return e-mails back to the customer.
The account manager should always call back and return e-mails to the customer. This is the way to establish a good connection between both of the parties.

- Do not plan. Just wait for the things to happen all by themselves. Do not take ownership of the project.
Half of the account management duties are concerned with planning… the other half is managing customers :).

- Do not inform the customer regularly for the execution of their project.
The customer should always be informed about how the project goes. And it is important to inform the customer even when there are only good news.

- Often go above the terms in the contract to make the customer happy.
A situation like this will happen to the account manager sooner or later. All additional work the customer is requesting should be discussed with supervisor and then it should be decided if the work should be done at no additional cost.

- Store negative emotions. Forget that this is just a business.
Sometimes everything goes wrong and the customer is very unhappy. At this point the customer is sometimes mean or very harsh with the account manager. But the account manager should always remember that it is just a business, and should not take it personally.

Top 5 Account Management challenges

- Ignorant/indifferent customers.
Ignorant customers who are ready to learn are not a problem, but indifferent customers who do not support the project and do not provide the materials/information on their end may even fail the project.

- Wrong rough estimation of the project.
That’s a very bad situation for the account manager when it happens. Usually this should be escalated immediately and the project should be returned to sales to be estimated and sold properly.

- Delays in the design and development of the product/project.
This could always happen. Though, a good account manager should have planned some additional time in the project/account plan to ensure some time shifts are possible.

- Major changes after the project is released live.
The customer just got his/hers project live and realized that’s not what they wanted. If the changes are significant, the issue should be escalated by the account manager and a decision should be made by a superior.

- Clients/Projects that are just too much pain in the ass.
We all know those kinds of people that would do anything to ruin our day. But it is even worse for the account manager to have such a customer because he/she needs to complete the project. As always stay professional and avoid any confrontations and pointless chat with the customer – just stay focused on finishing the project.

Top 5 Account Management advantages

- The complete project happens with the account manager.
It is fantastic to see how a piece of paper (contract) turns into a real, finished and great product. It is even better when the account manager knows he/she is the person, mainly responsible for this transformation.

- Account managers create connections.
Many customers + many projects = many connections. If the customers are happy with the account manager’s work they could help advancing his/hers career and also they could be useful in many other situations.

- Every new customer/project is a new challenge.
And new challenges are great and always welcomed.

- Developing many skills.
The account managers need to have knowledge and skills in everything – design, programming, plans, marketing, seo, communications, leadership, etc… It is great to be a good “jack of all trades”.

- Account managers are better looking than the rest of the team.
It is simply a fact :)

Basics of SCRUM

Scrum is agile Project Management methodology and agile means very flexible kind of approach. If you compare Scrum to traditional project management methodologies you will notice that Scrum is quite different. In traditional project management approach you first elaborate strategy and then project management plan, project checklist, Gantt chart, task list, project specifications, etc… and in agile methodologies you just need a list of features (products/projects) your company wants to build and you are completely free to take the shortest and most flexible way in delivering those products/features.

But let’s talk about the basics of Scrum. Scrum is very good because the product owner has a complete short-term control of what is going to be produced and what features should be implemented.

The three significant dimensions in Scrum are

- Requirements
- Technology
- People
The requirements are part of the projects, features and products to be developed and delivered.
The technology should be carefully selected to optimize the time and the cost of the development.
The people are the ones involved in managing, developing, testing and delivering the final feature/product.

Roles in Scrum

- Product owner
- Scrummaster
- Team
The product owner is the guy who represents the stakeholders (the people funding the enterprise) and he has the right and responsibility to create a list of products/features (called product backlog) to be developed. Also the product owner should set the priority for every item in the product backlog. The product owner is also responsible to explain the products/features functionality to the team in a clear manner.
The Scrummaster is the Project Manager in the Scrum team. This is the guy who teaches all team members how to use Scrum, helps the product owner with the product backlog list, keeps track of the features to be developed in the sprint backlog list, arranges sprint planning and daily Scrum meetings and supports the team in developing the features on time. The Scrummaster should also help clarifying the requirements of the features and the projects. The Scrummaster also takes active part in the “demo meeting” where the new features are presented.
The team consists of designers, front-end developers, back-end developers, Q/A specialists, Marketing Specialists, Support team members, etc… The team is fully responsible for providing deadlines and estimations for every single project/feature.

Scrum documents

- Product backlog
- Sprint backlog
- Burndown chart
The product backlog is the initial document containing all the projects and features the product owner needs implemented. The product owner could add new items to the product backlog at any time.
The sprint backlog contains the projects/features to be implemented in the current/next sprint period.
The burndown chart shows the work to be done (estimated in hours or days) in the sprint and dates. It should diminish with every day passing.

Scrum protocol

Sprint planning meeting 

This is the initial meeting where the product owner presents the product backlog and discusses it with the Scrummaster and the team. The team estimates every product/feature in the product backlog. The Scrummaster should write down the exact requirements for every product/feature to ensure they are clear enough. The product owner should set priorities of all products/features and based on the Scrum sprint length (usually between 15-30 days) the Scrummaster fills the items that are set with highest priority and would fit within the sprint period in the sprint backlog. After the sprint meeting is over the requirements and product/features specifications cannot be changed.

Sprint

The idea of the sprint time is to ensure that the team will not be bothered and will work on a products/features without the requirements being changed for a fixed amount of time (usually 15-30 days). During that time the Scrummaster organizes daily Scrum meetings to keep record of the progress and support the team.

Daily Scrum

The daily Scrum is a short meeting where every team member should be able to answer those questions:
- What have you done since the last daily Scrum?
- What will you do until the next daily Scrum?
- What type of obstacles/difficulties do you encounter?
The last point is extremely important and if a team member encounters serious difficulties the Scrummaster should encourage the other team members to help and should try to resolve the problem with the help of the team.

Sprint review meeting

The sprint review meeting is arranged to demonstrate the new products/features developed by the team through the sprint period. Usually the team member who worked on a particular product/feature/task should demo it but it is also possible for the Scrummaster to demonstrate the new features implemented.

When should (not) we use Scrum

Scrum means flexible. It is best incorporated with organizations or projects that require a lot of small to medium estimated features to be implemented. Scrum allows the product owner to set new priorities on relatively short terms. It is vital that the Scrum team members are reliable, self-motivated and eager to meet the deadlines.

Traditional project management, involving project strategies, plans, checklists could be used (even on top of Scrum) when a company is doing large scale projects and there is an absolute clarity on what is needed to be delivered in the end – for example a huge web project from scratch that needs many features and functionality implemented before even the beta is ready. Usually the development time of those projects could be more than a year. Scrum could be used within the teams if there is a lot changes requested and there is a great chance that the final product will be completely different compared to what was initially planned/purchased and paid.

Scrum is especially good for startup businesses where the companies need to be extremely flexible and need to turn around 180 degrees very quickly.

Introduction

Hi guys, I am Simeon and I am a guru in the fields of Project Management, SEO, Marketing ... and sports, mainly bodybuilding :). I will be using my Professional-tech blog to share my knowledge with you on all those cool topics.

I am currently based in the London area and I have experience on "how to relocate to London" - so expect some articles about that as well.

Cheers!