Skip to main content

Tag: Requirements

Managing Requirements Gathering

Written by Mike Lecky on . Posted in Articles. 5 Comments on Managing Requirements Gathering

A structured approach to requirements gathering during the early stages of a project can pay large dividends later.

Have you ever entered into a project as the manager and been expected to follow a previously established process or project methodology? Has there also been an expectation to meet certain milestones within certain dates, regardless of the scope of the project? Do you find there are great pressures to rush planning and requirements definition activities?
I’m sure you can relate to these questions. And to deal with these time pressures there are a few techniques you can build into your project early to help gather requirements quickly.

A growing number of organizations have developed project management frameworks in order to achieve a degree of structure. These processes can be viewed as management controls over projects. They are intended to not only standardize activities in the organization but also add visibility to the project progress, support decision making and streamline the work to ensure success.

These frameworks may be large and broad such as those laid down in SDLC (Systems Development Life Cycle) policies. These would apply generally across large corporations and often highlight management decision points in the process. Other frameworks are more detailed and fitting to the mandate of departments they support. Many smaller organizations are highly focused on a certain types of project deliverables and their processes are tuned for this.

In any case, all these frameworks are only as good as the definition of requirements for the projects that must follow them.

We all know that if the project deliverables and the criteria for success are not clearly defined then the chances of meeting scope, schedule and budget objectives are limited.
And yet I find that many of these staged processes come with management expectations to rapidly move through early stages.

Depending on your project situation there are three techniques you might consider to gather requirements information.

First, you can build a series of formal interviews with key individuals into your project plan. This is by far the most common approach. The best results are achieved by keeping the sessions formal and making sure the interviewees have the authority to make decisions on requirements. It is important to very clearly articulate the objectives of the interviews and follow a pre-prepared agenda, which should be sent out ahead of the interview.

The second approach is to use surveys. This might work well in situations where a large number of people need to be consulted or if the individuals are geographically dispersed. It can often be difficult to arrange a good time to meet with a group of people who are in different time zones. Keep the survey questions short and to the point. A survey with 10 questions delivered in a web-based format is likely to yield the best response rate.

Finally, you can conduct a facilitated requirements gathering session. As with the interviews, be sure the attendees have the authority to make decisions on requirements. A successful facilitated session requires planning. As a facilitator, you’ll need to consider a neutral meeting location, the session duration, how consensus will be achieved and the agenda, which may include an icebreaker. In some cases a short training period is helpful to level set attendees.

All these techniques should be followed up with a summary of the information gathering activity (i.e. minutes or survey results) and a list of follow-up activities for completeness.

Regardless of what project methodology you are expected to follow, if you get sponsor buy-in to a formal requirements gathering phase and use these activities early in your project, you’ll be sure to firm the requirements and get more issues on the table sooner. Later during project execution you’ll be much better positioned to monitor and control the project and manage the various scope changes that may arise.

The Rules of Lean Project Management: Part 2

Written by Claude Emond on . Posted in Articles. 3 Comments on The Rules of Lean Project Management: Part 2

This is my second blog entry on the main rules of Lean Project Management, as I see them. It is somewhat linked to the first one, the “Last Planner” rule which says: “The one who executes the work is the one who plans the work.”

What type of work should the Last Planner plan to execute ensure the success of his/her part of the project? The Lean Construction Institute[1] proposes a very simple answer to this question. Projects can be successfully managed by planning and executing reliable promises. What are reliable promises? They are small deliverables that one agrees to complete in a very small timeframe, usually on a weekly basis. This is done for the ongoing project phase/stage and, if we really know what we are doing (according to rolling wave planning principles[2]), it is usually possible to cut the project into more manageable tiny bits. This approach, known as the Percent Plan/Promises Complete (PPC) is a mix of:

  • The agile software development “timeboxing”[3] approach, applied on an individual basis and
  • Earned value management using deliverables realised as a measure of project performance achievement, the ultimate seeing is believing measure.

Cutting projects into very small promises that we can literally see at the end of each week is effective in at least three ways:

  • First, you are in a position to see rapidly tangible progress on the project
  • Second, you can also quickly see when the project is getting off track and correct the course while time and cost variances are still small enough to be correctable.
  • Third, according to research by Goldratt, among others, productivity is greatly improved since reduces the time for the Last Planner where to pick up the work still to do after being interrupted. The work then has to be rescheduled to meet timelines. According to some time management studies, people spend in average close to 50% of their workweek on not-planned-for urgent work that comes in the form of frequent interruptions, frequent meaning on average every 30 minutes. Sound familiar?

Using weekly PPC as a measure of progress also has the advantage of giving early feedback about how and where to improve project delivery performance. Some empirical data[4] show instances where project teams managed to increase their PPC from 50 % at the start of a project to more than 80% within a 10 to 12 week timeframe, which is the equivalent of a 60% increase in speed of delivery.

Tracking small deliverables is very simple to do and does not require a complex reporting system (computing timesheets, project expenses, etc.) to accomplish. In all the things I propose, this is also the one approach that the vast majority of participants in my workshops like the most and want to put into place in their organization as soon as possible. And frankly, I believe that if you stick to delivering those small promises, and succeed most of the time, you will discover when you receive your “hours spent and/or incurred costs” report (usually containing one-month old obsolete data), that you are on budget. You already know that you are on time, because you see the promises coming out every week.

So LPM rule No. 2 is: “Do not track time (effort) or cost; track small promises that you can see over time”

And if you want to put together your PPC system fast, there is help available. Just read Hal Macomber’s excellent article “Securing Reliable Promises on Projects”[5] and you will be up and running fast-delivery projects successfully in no time at all.

1 http://www.leanconstruction.org/
2 http://www.maxwideman.com/issacons/iac1077/tsld002.htm
3 http://en.wikipedia.org/wiki/Time_boxing
4 https://www.projecttimes.com/wp-content/uploads/attachments/LCICurt.pdf
5 https://www.projecttimes.com/wp-content/uploads/attachments/reliable_promises.pdf

Putting the Project Manager in the Driver

Written by Cynthia Low on . Posted in Articles. 4 Comments on Putting the Project Manager in the Driver

A project manager’s training, skills and techniques serve to accomplish one major objective; to provide the project manager a vehicle to successfully attain a goal or target. As with any vehicle the operator must have some training to maneuver and control its progress. The vehicle itself provides no guarantee of reaching the destination or of successful goal attainment. Vehicle quality may also have a bearing on the overall performance and experience. It is the driver that must determine the direction, the route and the rate of speed given the vehicle’s characteristics. Such is the case with project management.

A project manager’s training is relatively well defined. The training or vehicle, so to speak, comes in many shapes and sizes with different levels of performance. Suffice to say that vehicle specifications are generally standard in that there are basic requirements to creating a mode of transportation. Not unlike a project manager’s training. There are basic requirements in a PM’s training that are relatively standard. Take the PMBOK for instance representing the specifications to assemble a knowledge-based vehicle for the project manager to utilize. Once mastered it requires that innate or learned ability to take that vehicle and embark on a journey towards a goal. In most cases, as the project manager/driver, you will have passengers who rely on your judgment and will experience your abilities as a driver and leader. On occasion your passengers or team members will have some input that you may wish to consider in your journey.

This brings us to the next level of a project manager’s development, which deals with maturity and ability. Not all trained drivers can master a vehicle with ease, so too is the case with project managers. A fortunate few are born with an innate ability and reach their comfort zone relatively easily and quickly. The vast majorities are left with a time of trial and error and sweating the details until it becomes second nature. Many of us struggle to get the feel of it and find ourselves constantly challenged in an effort to achieve balance from project to project.

Armed with training, experience and a few times at the wheel you tend to organize your mental stimuli on each project to determine what needs your attention most, when is it needed, and to what level of involvement it is needed. It helps also to determine what requires little of your attention. Consider your progress as a driver: As you became more adept and mature, you tended to focus on the aspects of driving that got you safely and expeditiously to your destination. During your initial days at the wheel, you read each and every sign posted and followed every marking so as not to miss any details. In some cases this attention to detail affected your progress, or may have even got you lost, which left you exhausted and consumed when you finally arrived at your destination. Similarly, with project management we must achieve a level of maturity from the knowledge and experience that helps us zero in and ”feel” the project, not just read all the dashboards and reports to reach conclusions.

There are some basic steps to acquiring a comfortable level of maturity. It takes a well-trained eye and a bit of experience to develop to this stage. Following an in-depth and clear understanding of the undertaking, the PM will recognize three aspects that play a leading role in determining the project’s “feel”. The first aspect is Awareness. The second is Priority and the third aspect is Urgency. (APU).

Awareness involves information gathering. It requires early stage analysis of scope, data, documents, contracts, organizational structures, politics, personnel and whatever details may be available. As the project develops through its stages so does the requirement to become aware of each added feature to the overall scheme. Awareness is primarily a quantitative analysis. It requires some judgment but also requires considerable understanding of the role each piece of knowledge base plays in the big picture. This step gives you the basic raw materials needed to assemble the framework from which you will build your model of management. You will, in all likelihood, have a checklist of standard features you feel are required to complete your model of how the project should be managed. You may introduce features such as scheduling or cost control, or you may find that your model requires expertise and, therefore, additional resources. After completing this stage of knowledge absorption, the next step is setting the priorities.

Priorities involve identifying those features or activities you absorbed in the awareness stage, which will create a “no go” situation in your overall progress if a non-compliance should occur. A non-compliance can be a delay in progress, a missing document, or an unfulfilled step in the process. As a project manager it becomes crucial to identify these potential non-conformances and devote additional attention to them to prevent them from crippling your program. It serves to make efficient use of the PM’s time, thus avoiding excessive effort on non-essential activities. In many cases, a well-defined network schedule or cost plan is very useful in identifying these priorities. However, in several instances the plan may not hold enough information to be useful in all cases. Take for instance a departmental political situation that may be affecting a judgment call crucial to the project. In another instance a minor unresolved engineering detail may delay a larger issue of information, or a financial foul-up could stop activities due to lack of funds. Being fully aware of the critical aspects allows the PM to surgically focus his attention. In addition, it is vital to document and communicate these priorities and focus on them during meetings and dealings with members of the project team. This increases the team’s awareness and places more eyes and ears on the potential problem, which then leads us to the aspect of urgency.

Urgency is the level of effort that will be injected into each feature of your program or project, based on its priority. Urgency must be measured very carefully to avoid the “cry wolf” syndrome. The PM with his awareness stage completed, his priorities determined and with his judgment in tact will then decide how hard to press on the throttle. It is this aspect of his responsibilities that may determine the success or failure of the project. Urgency is generally preceded by a decision to act in some form. Similar to driving a car, reckless or indiscriminate use of urgency fosters fear and distrust thus loosing the support and confidence of those who you need most to achieve success. Applying urgency appropriately and justifiably helps build trust in your judgment and confidence in the actions needed to resolve a crisis. It also helps you attain maturity and respect.

In conclusion a project manager needs formal training in the skills of PM but must also develop a sense of awareness, priority and urgency to apply the skills learned and needed. This sense quite often is the result of trial and error through one’s developmental stages or via a mentoring program. Experienced managers generally recognize the difficulty in transferring this sense, or savvy, to new managers since, having spent years developing this intangible in themselves, they often feel that only time and practice can help develop it in a new PM.

Robert Mattia is a project manager and operations manager with The State Group International L.L.C, which is embarking on a joint venture business development with S.S. Lootah International in the UAE. He has been with The State Group for the last 14 years and possesses a Bachelor of Technology from Ryerson Polytechnical University (1978) with a major in Project Management. He is a designated A.Sc.T. with the Ontario Association of Certified Engineering Technicians and Technologists, and holds a Certificate in ADR (Alternative Dispute Resolution).

Effective Communication

Written by Ilya Bogorad on . Posted in Articles. 5 Comments on Effective Communication

Breakdown in communications is often cited as a reason for failure in negotiations, initiatives, projects and organizations. I have yet to see project Lessons Learned, which did not feature communications as one of the competencies to be improved. We are told that communication is something we always must do more of, that it is impossible to over communicate…yet, breakdowns keep happening, to keep the Lessons Learned coming.

So, why is it such a problem?

The following are five reasons that cause or aggravate deficiencies in communication. You may be able to observe all of them in your organization.

  1. Vague responsibilities and poor discipline
    A trivial issue of failing to spell out who is responsible for dissemination of information and facilitation of the communication process can be easily overcome by creating a communication plan, either verbal or written (whatever is appropriate) and sticking to it. Are you delegating it to someone? Be specific on the expectations, the media and the protocol.

  2. Lack of transparency
    “We cannot make it public knowledge”
    “It would not be appropriate”
    “We need to ensure X is ok with us saying this, but he is on vacation for two weeks”
    Sounds familiar? Of course it does. Instead of communicating openly, organizations routinely engage in political hopscotch, which unavoidably produces a brood of worst kept secrets, gossip and uncertainty. And uncertainty kills productivity.
    I command you – cut through this stuff, be proactive and foster the spirit of transparence within your organization. Squash gossip by providing trustworthy information.

  3. Efficiency
    The human brain is an incredibly efficient device, capable of processing massive amounts of information quickly and efficiently. Such processing power is possible due to the presence of synapses, which allow neutrons to exchange information in a parallel mode. It is the power of our brains that makes the otherwise pretty unimpressive hairless ape the most powerful animal on Earth.

    Those organizations that encourage communication in all directions and at all levels, not unlike in a neural network, are the ones that are nimble, quick and powerful. They thrive.

  4. Poor content
    Communication that lacks substance and relevance, no matter how wordy or even eloquent, is useless if not harmful. Provide information, not data; ideas, not words.

  5. Lack of discipline
    Nothing to say here but that we all goof off, forget, procrastinate and drop the ball. There is no excuse for it. Maybe I‘ll talk about how to deal with these later… perhaps next time… if I remember!

By the way, I’ll be speaking on the Best Practices in Business Cases at the Toronto Chapter of the International Institute of Business Analysts (http://www.iibatoronto.org) on May 28. Check with them if you’re interested in attending as a guest.

Myths, Mistakes and Assumptions

Written by Cynthia Low on . Posted in Articles. 4 Comments on Myths, Mistakes and Assumptions

Editor’s Comments

“Don’t assume” is advice that, over the years, has been handed out by those who have “been there” to those who haven’t yet been there. It’s advice well worth considering because many of these assumptions turn into traps. In Unquestioned Assumptions: Costly Mistakes, Don Wessels discusses how assumptions, often mistaken as standard business practices, go unquestioned during project manager selection, often with very negative consequences.

Regular contributor, Chris Vandersluis, revisits a subject he’s talked about here a number of times in the past. He says they have become a fact of life for senior management and, in Dashboarding Redux, he takes a look at the different types of dashboards available and how they can provide an onscreen view of key performance indicators, with your choice of how and what to display. But, he says, beware of possible pitfalls.

Blogger Andrew Miller, questions the need for budgeting in running a project, but acknowledges that budgets are important as long as their sensibly set and approved. Mike Lecky weighs in with some thoughts on the ongoing discussion about the PMO.

If you’re reading this during ProjectWorld in Toronto, we hope you’re finding your visit rewarding and that you’ll drop by our booth to say hello. Wherever you are, we hope you find this a thought-provoking issue of Project Times and that you’ll share your thoughts with us.