Select Page

Categories

Customer Management in Project Management

Customer Management in Project Management
By Dave Nielsen

It is fair to say that good communications is essential to the task of managing the customers of a project, but good communication is tool that will enable you to improve on your management style. Managing your customer requires you to understand who your customer is, what they need from the project you’re managing, how to set reasonable expectations around what you can deliver, and demonstrating to them that you’ve delivered.

Here are some tips that will help you establish and maintain a good working relationship with your customer from the beginning of the project, through to closeout.

Identify Your Customer

This may sound simplistic, but in most software development projects distinguishing customers from other stakeholders can be tricky. Here’s a golden rule for identifying your customer: the ultimate customer is the one that signs the cheque. This person is frequently referred to as the business sponsor in software development projects. Read the Complete Article

Project Management Activities

Project Management Activities
By Meade Rubenstein

When you start a new job, you focus on where you’re sitting, who you’re working with, what your boss expects from you and how you can accomplish your job. The basics are: know where you are, know where you need to get to and develop a plan to accomplish that in the most effective and efficient way. These are the same steps every one follows in some manner.

Know where you are

As odd as it may sound, this is an often overlooked step for project managers. You might start moving towards your destination, but without knowing where you are how can you determine the overall effort to get there OR even the feasibility of accomplishing the journey? Want to take a trip to Wyoming and don’t know what planet you’re on…good luck.

What is there to know about where you are? And why is it important? Read the Complete Article

Non-Functional Requirements in IT Projects – Minimal Checklist

Non-Functional Requirements in IT Projects – Minimal Checklist
By Mike Griffiths

All IT systems at some point in their lifecycle need to consider non-functional requirements and their testing. For some projects these requirements warrant extensive work and for other project domains a quick check through may be sufficient. As a minimum, the following list can be a helpful reminder to ensure you have covered the basics. Based on your own project characteristics, I would recommend the topics are converted into SMART (Specific, Measurable, Attainable, Realisable, Timeboxed / Traceable) requirements with the detail and rigour appropriate to your project.

Security

  • Login requirements – access levels, CRUD levels
  • Password requirements – length, special characters, expiry, recycling policies
  • Inactivity timeouts – durations, actions

Audit

  • Audited elements – what business elements will be audited?
  • Audited fields – which data fields will be audited?
  • Audit file characteristics – before image, after image, user and time stamp, etc

Performance

  • Response times – application loading, screen open and refresh times, etc
  • Processing times – functions, calculations, imports, exports
  • Query and Reporting times – initial loads and subsequent loads

Capacity

  • Throughput – how many transactions per hour does the system need to be able to handle?
Read the Complete Article

Must-Have vs. Nice-to-Have Requirements

Must-Have vs. Nice-to-Have Requirements
By Jessica Popp

In addition to checking for solid requirements using the SMART methodology it is important to properly prioritize or categorize the project requirements. This can become especially critical in the large project or project with seemingly unrealistic expectations. There are many ways to categorize these; personally I like to apply the easily understood labels of must-have and nice-to-have.

This method is easily understood by the customer and provides the project manager with a significant amount of latitude for negotiation later in the project, the importance of which cannot be underestimated.

So the way it works is quite simple. After all of the requirements have been recorded, the list is re-visited with the customer to specify each requirement individually as must-have or nice-to-have.

  • Must-Have: this is any requirement that absolutely has to be delivered for the project to be considered successful. This helps create the base set of expectations with the customer.
Read the Complete Article

Requirements and Expectations in Project Management

Requirements and Expectations in Project Management
By Bernadette St. John

One of the most critical factors for project success is to meet (or beat) the customer’s expectations. Sounds easy enough, but unless you can read minds, it can be a challenge to really know what the customer expects. Documenting and discussing requirements upfront is one of those steps we all wish we could skip or at least get through faster, but not doing it well usually leads to disconnects and frustration further down the line.

Customers are usually too busy with their day-to-day responsibilities to devote much time to thinking through in detail what they need from a project. They either assume that the project implementers understand their needs as well as they do (very unlikely), and are surprised when the resulting deliverable lacks something that ‘obviously should have been there’. Or, customers do not think through their own requests in depth and, once implemented, have to deal with the unintended consequences of their request. Read the Complete Article

The Six Phases Of Project Management – Definition Phase – The Importance of Involving Users

The Six Phases Of Project Management – Definition Phase – The Importance of Involving Users (#4 in the Hut Project Management Handbook)
By Wouter Baars

During the definition phase of a project that involved developing a web application for a consortium of large organisations, no agreements were made concerning the browser that would be supported by the application. The consortium assumed that it would be Microsoft Explorer, because it was the browser that ‘everyone’ used. The programmers created the application in Firefox, because they worked with the browser themselves and because it had a number of functions that were particularly useful during the development. Because most of the websites that are made for Firefox also look good in Explorer, the difference was initially not noticeable. Near the end of the project, however, the customer began to complain that the website ‘didn’t look good’. The programmers, who had been opening the site in Firefox, did not understand the complaint. Read the Complete Article

The Six Phases Of Project Management – Definition Phase

The Six Phases Of Project Management – Definition Phase (#3 in the Hut Project Management Handbook)
By Wouter Baars

After the project plan (which was developed in the initiation phase) has been approved, the project enters the second phase: the definition phase. In this phase, the requirements that are associated with a project result are specified as clearly as possible. This involves identifying the expectations that all of the involved parties have with regard to the project result. How many files are to be archived? Should the metadata conform to the Data Documentation Initiative format, or will the Dublin Core (DC) format suffice? May files be deposited in their original format, or will only those that conform to the ‘Preferred Standards’ be accepted? Must the depositor of a dataset ensure that it has been processed adequately in the archive, or is this the responsibility of the archivist? Which guarantees will be made on the results of the project? Read the Complete Article

SMART Requirements – Time-bound (Timely, Traceable)

SMART Requirements – Time-bound (Timely, Traceable) (#6 in the series SMART Requirements)
By Jessica Popp

Time-Bound (timely, Traceable): where appropriate each requirement should be time-bound or specify by when or how fast a requirement needs to be completed or executed. In software engineering, you may see the “T” in SMART being used to mark whether a requirement is “traceable”, which is my opinion is a separate but important topic in developing software. For this general requirements overview, the focus will be on the time-bound requirement.

  • Weak Requirement: The report will be available soon after month-end close.

    Why is it weak? Who is to say what is “soon”? You cannot rely on what you consider to be reasonable expectations of the customer. You may know the time cycle of month-end close and that it takes the first 5 days of the month to complete. The customer may assume that soon means on the 1st of the month.

Read the Complete Article

SMART Requirements – Measurable

SMART Requirements – Measurable (#3 in the series SMART Requirements)
By Jessica Popp

Measurable: this answers whether you will be able to verify the completion of the project. You should avoid signing up for any requirement that cannot be verified as complete. These are especially risky when you use non-quantitative terms (best, optimal, fastest) for acceptance criteria.

  • Weak Requirement: The system shall have an optimal response time for the end-user.

    Why is it weak? There is no way you can be successful with this requirement once the new system goes into production. It’s similar to being specific, in that optimal is not defined and really cannot be defined.

  • Strong Requirement: The system shall have user response times on user click-events that are 5-seconds or less during business hours of 9AM-5PM, Mountain Time, Monday-Friday.

    Now this requirement can be measured once the system is in production. In the first example, you might end up in a never ending loop with the customer after the system is in production trying to define “optimal.”

Jessica Popp is a practicing project manager in software engineering. Read the Complete Article

SMART Requirements – Specific

SMART Requirements – Specific (#2 in the series SMART Requirements)
By Jessica Popp

Specific: a good requirement is specific and not generic. It should not be open to mis-interpretation when read by others. This is the most important attribute to get correct. Avoid using conjunctions (and, or, but) as they can confuse or misconstrue the meaning. Avoid indeterminate amounts of time (soon, fast, later, immediately) as they are open to wide mis-interpretation which results in dissatisfied customers.

  • Weak Requirement: The report displays all the monthly data from the marketing department.

    Why it is weak: Anytime you see all, always, never and other global adjectives, beware. What if the marketing dept adds more data; do you need to immediately update the report? What if “all the data” that you are aware of from marketing is different than what your customer (the report requester) perceives as “all the data”? Even if you and the customer agree, what about a third reader?

Read the Complete Article

Recommended PM App

Recommended PM App

Categories