Project Management

Definition of “Project Management”

Project management can’t be properly defined without defining a project first; A project is a piece of planned work or activity that has a set of interrelated tasks to be executed over a period of time and within certain limitations such as cost, to achieve a certain purpose. A project is unique meaning that it is not a routine rather a set of specific set of task designed to accomplish a singular goal.

Project Management is the discipline of using established principles, procedures, policies, knowledge, techniques and tools to manage a project from its conception through its completion. It is commonly abbreviated as PM.

Project management processes fall into five groups:

1. Initiating
2. Planning
3. Executing
4. Monitoring and controlling
5. Closing

Project management knowledge draws on ten areas:

1. Integration
2. Scope
3. Time
4. Cost
5. Quality
6. Procurement
7. Human resources
8. Communication
9. Risk management
10. Stakeholder management

Management in general is concerned with all of these, but project management brings a unique focus shaped by the goals, resources and schedule of each project.

Roles and Responsibilities of a project manager

Project managers can employ a wide variety of methods and approaches to run projects, generally selecting the best approach based on the nature of the project, organizational needs and culture, the skills of those working on the projects, and other factors.

Managing a project involves multiple steps. Although the terminology for these steps varies, they often include:

• Defining project goals
• Outlining the steps needed to achieve those goals
• Identifying the resources required to accomplish those steps
• Determining the budget and time required for each of the steps, as well as the project as a whole
• Risk analysis
• Managing risks and issues
• Overseeing the actual implementation and execution of the work
• Delivering the finished outcome.

Now I think we've covered most of the basics of project management so now we can talk a bit about my experience…

Being a complete novice, JJC (Jonny Just Come) as we say here, on my first day I made massive blunders but with mistakes we learn right?… As we go a long I will list those mistakes and corrections also let me list out a few key things I learnt on my first day.

• Do not command people (unless in the military)
• Do not threaten your team mates
• Do not be harsh (minimal trolling is allowed)
• Be nice and gentle
• Advice your team
• Give them feedback as often as possible
• Encourage your team as much as possible
• Help your team structure themselves, test what they've done and guide them to do the right thing
• Help coders stay structured and moving forward fast
• Make sure no one is idle

What a first day huh?… The interesting thing is that this was just in the morning, a lot still happened later that day.

The field of project management I'm being trained in is called Agile Project Management.

When it comes to agile project management roles, most agile processes — Scrum in particular — do not include a project manager. Agile “project manager” roles and responsibilities are shared among others on the project, namely the team, Scrum Master and product owner.

Within agile development, Scrum has the most to say about exactly what is agile project management. So let’s use Scrum as our model for answering this question. On a Scrum project, there are three roles: product owner, ScrumMaster and team.

There’s a lot to talk about when it comes to agile project management, and that would take so much out of this article and what I really want to focus on is teach and show you most of what I've learnt so far, not write an essay… well maybe along the line I might, but for now as we go along, I will leave you with links to read in your spare time.

• Mountain Goat Software — Learn about Agile

When you are given the role as a project manager in a company, the title can get to your head if not careful you must not get corrupted by it’s seductive power.

Another thing I learnt was how to write agile user stories, stories that are are easily understood by the coders and testable by anyone.

How to write user stories.

User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. They typically follow a simple template:

As a < type of user >, I want < some goal > so that < some reason >.

<type of user>, <action>, <expected outcome>

“One of the benefits of agile user stories is that they can be written at varying levels of detail. We can write a user story to cover large amounts of functionality. These large user stories are generally known as epics.”

An example of an epic is

• As a user, I can reset my account password.

Normally, an epic is to large for an agile team to complete because of the complexity, it is normally broken down into smaller user stories known as sprints which can be easily worked on. The example above can be broken down into a dozen stories apparently if not more, which includes these two:

• As a user, when I click on the ‘reset password’ link, I should be redirected to a page requesting for my valid email address.
• As a user, when I provide an email which exists in the database, I should be sent an email with a link to reset my password.

With this now, more detail has been added to the earlier epic, the password reset feature can be worked on and tested in it’s individual parts making it easily understood by the coder.

“Stories are not meant to be technically prescriptive; that is, they do not need to specify any information on how exactly your engineering team could implement the functionality in question. Stories clarify the reason for the functionality and what specifically that functionality is”

User stories are best written following the INVEST model.

• Independent — Can be released without any dependencies
• Negotiable — Ready for discussion and can be adapted based on team input
• Valuable — Adds values to the user
• Estimatable — Can be estimated by the dev team based on it’s relative complexity
• Small — As small as possible while still providing real user value
• Testable — Contains the acceptance criteria

With all these, you may be asking “who writes user stories”?

The answer is, anyone can write user stories. It is the product owner’s responsibility to make sure that there’s a back log of stories, but it does not mean that the owner is the only one that writes all the stories. Over the course of an agile project, every team member is expected to write a user story as the project progresses, it is the job of the project manager to make sure all stories and tasks stay and remain in the scope of the project, break down stories and task to their smallest valuable parts and keep the entire team motivated, on track and moving forward.

Project Management Software Tools

When it comes to project management, there are a wide variety of software tools that aid in structuring and planning.

Project management software is software used for project planning, scheduling, resource allocation and change management. It allows project managers (PMs), stakeholders and users to control costs and manage budgeting, quality management and documentation and also may be used as an administration system. Project management software is also used for collaboration and communication between project stakeholders.

Though project management software is used in a number of ways, it’s main purpose is to aid the planning and tracking of projects: such as project component, stakeholders, and resources.

Project management software caters to the following primary functions:

• Project planning: To define a project schedule, a project manager (PM) may use the software to map project tasks and visually describe task interactions.
• Task management: Allows for the creation and assignment of tasks, deadlines and status reports.
• Document sharing and collaboration: Productivity is increased via a central document repository accessed by project stakeholders.
• Calendar and contact sharing: Project timelines include scheduled meetings, activity dates and contacts that should automatically update across all PM and stakeholder calendars.
• Bug and error management: Project management software facilitates bug and error reporting, viewing, notifying and updating for stakeholders.
• Time tracking: Software must have the ability to track time for all tasks maintain records for third-party consultants.

A good example of a project management software is Pivotal Tracker.

This has been the main software I've been using so far, not to discount the others I've come across such as airtable, trello, and teamgantts, but I will speak more about them in a future article.

Pivotal Tracker covers all the primary functions a project management software is meant to cater to although I personally still find the time tracking feature in this tool confusing, but where pivotal tracker shines is in “Task management” and “Bug and error management”. This shining feature of pivotal is the way pivotal labs have categorized stories. Personally I don’t think writing stories the pivotal labs way is for the faint of heart especially when managing a large team but the upside is that if done properly, you stand a greater chance of improving your team’s efficiency by a lot, because it gives your team a streamlined approach to tackling the tasks given to them, because the stories are differentiated by type;

• Feature stories — “ Feature stories are designed to explain the who, what, and why of the smallest incremental feature that can be added to a product that delivers user value. Feature stories are pointed by the development team and are estimated by complexity rather than by the time it will take to complete the feature. They are written from the user’s perspective and act as lightweight requirements documentation for a development team”
• Bug stories — “A bug is a defect in a feature that has already been accepted, regardless of when it was accepted”
• Chore stories — “A chore is a story that is necessary but provides no direct, obvious value to the user (e.g., ‘Setup new domain and wildcard SSL certificate to create test environments’ or ‘Evaluate tools for system troubleshooting’)”

This approach aids in team structuring, and as I mentioned earlier, if a PM can master this pivotal approach to agile management, ensure your team’s productivity and efficiency going up… explains why Mark hammers on me to learn how to use this properly.