Tag Archives: requirements

Your Customers Don’t Care

I was in a local cafe the other day working on a Kanban training course I’ll be making available sometime soon.

I grabbed the usual coffee for fuel and then a sugar avalanche of a toffee bar caught my eye. And I bought it. Because I have no impulse control whatsoever.

I chewed the first wonderful bite, eyes closed, prepared for the caloric coma. Continue reading

Scheduling as Premature Elaboration: You?re Doing It Wrong

Scheduling is what project management is all about, right?

Among the plethora of project management tools available, what aspect is most widely promoted?

Jumping right into MS Project or any other scheduling tool is a mistake.

Projects like this are built on very unstable footing, and it’s likely they will fall apart in some way.

It’s just not safe.

If you haven’t fully developed a good Work Breakdown Structure (WBS)/PBS, requirements, and Basis of Estimates (BOE) before you start scheduling (and subsequently estimating costs and setting a budget), you’ve done it wrong.

So please, don’t open up a scheduling tool the moment you start a new project.? For me, there is a general order of operations to acheive project planning which is built on a sturdy foundation.? I don’t care if it’s waterfall, agile, whatever.? There are pieces between steps that go back and forth a bit before moving forward, but in general:

  1. Why – (business case, charter)
  2. What – (charter, WBS, requirements, use cases/user stories)
  3. How/Who – (ConOps, Trade Studies, Design, Basis of Estimates)
  4. When – (schedule, prioritized backlog)
  5. Iterate – (progressive elaboration, sprint cycle)

[All wrapped inside a Project Management Plan/Approach, based on proven system engineering/industry practices,? and supported by risk and configuration management.]

Note that MS Project or other scheduling tools don’t enter the picture until Step #4.? I have never heard a convincing argument as to why anyone would think of scheduling anything until you had a good grasp on the foundational prerequisites I list in steps 1-3 above.

So what do you think?? Does my take on this topic match up with your own, or are you mad at me now because I’m talking about you?? Either way, please leave a comment and let’s discuss what you think.

Requirements Gathering? Elicitation? No…

George Bridges, PMP

Requirements Development

A business analyst does not gather or elicit requirements.? They develop them.

In fact collecting requirements from stakeholders is a subtle problem for most people who are responsible for managing the requirements process.

The problem with gathering requirements

The problem with gathering requirements is that it implies that you already know the solution to the problem.? By collecting information, we determine the “real” problem(s).

Once we have confirmed the problem(s), we will move into the phase of developing requirements that will solve the problem(s) for the current project. What a Business Analyst or someone acting in that capacity should do is collect information from the stakeholders. This person should elicit the “right” information that will lead to the development of the requirements.

To do this, you need to have an elicitation plan that will guide you through the process of requirements development. ?So take the information you get from the stakeholders, analyze that information so that you can develop, analyze and write good requirements.

If you need a framework to work from, I suggest you check out the Business Analysis Body of Knowledge (BABOK), published by the International Institute for Business Analyst(IIBA) ?(www.theiiba.org) ….. more on this subject in my next blog.

[Editor’s loud mouth]

If you are reading this right now, what do you think of George’s distinction here between developing versus gathering or eliciting? Is it just semantics, or is this an example of language influencing practice?? I like George’s approach, mostly because I want to be sure new business analysts and project managers realize that you can’t just go to the customer and ask for their requirements.? (Well, you can….)? There’s a process of refining and as George points out, developing, those statements and documentation until they reflect what the project will truly seek to fulfill.

[/Editor’s loud mouth]

Performance Based EVM

Guest post by Travis Anderson

Hello all,

Many of us have experienced frustrations with obtaining useful program performance data. It is not always an easy process of maturing project management and earned value management best practices on our commercial/government contracts. Some days we feel like just giving up, especially during the variance analysis time of the month. Yet we know besides the fact there is a contractual requirement that deep down there is a real need for staying the course.

Useful performance data is dependent on so many different aspects of our programs that need to work in harmony such as systems/software engineering, project management, earned value management best practices. Not to mention other standard business contexts such as budget, organizational culture, individual participation, maturity of core competencies, and customer perception.

To prompt some discussion, I have attached below a one hour video link for you to view. The Performance Based Earned Value video is presented by Paul Solomon, PMP during a DoD Data Analysis Center for Software forum in August 2008.? He discusses some common performance related deficiencies and uses the concepts of PBEV to improve the usefulness of performance data by introducing a quality aspect. Topics related to CMMI, Agile, and Acquisitions are also discussed.

I am interested in your thoughts and comments.

Thanks

DoD DACS Video link ? Performance-Based Earned Value ?

https://www.thedacs.com/training/webinar_details.php?id=36

Performance-Based Earned Value ?

http://pb-ev.com/default.aspx

What Are Requirements?

Requirements - by secretlondon123 via Flickr

Requirements - by secretlondon123 via Flickr

Requirements are descriptions of the end-result of your project.? They are a way to gain consensus on exactly what it should do, and impose some constraints as well.

Good requirements DO NOT impose a particular solution unless there is a valid business reason.? Let me explain.

A Tale Of Two Requirements

  • Perform [function] with less than [some constraint or specification] delay using [specific software program or system].
  • Perform [function] with less than [some constraint or specification] delay.

I am NOT saying these are great examples of requirements, I could do a whole training course just on the topic of requirements.? Just note that in the first example, the requirement mandates a particular solution.? This may be valid, but watch for it like a hawk.

Many times, the solution is assumed.? Instead, it should be up to the experts on the project team to figure out the best solution.

Oh, and if you want some more info on this topic, keep the following in mind and click through to the article:

Good Requirements ARE SORTA NUTS

Are you eligible to appear in the PMP exam?

Flickr Attribution - worak

Flickr Attribution - worak

So, you have been hearing of the advantages of being a PMP and have finally decided to appear in the exam!

Great! Before you get set to prepare for this exam, you need to spend a moment verifying whether you are eligible to appear in it. Through this article, I will help you do exactly this.

So, what is it that you need to be eligible?

(1) You should be able to show a minimum of 4500 hours of project management experience, if you possess a Bachelor’s degree (or a global equivalent), or a minimum of 7500 hours of experience otherwise. Also, this experience should span across all the 5 process groups. So, you should specify your experience in Initiating, Planning, Executing, Monitoring and Controlling, as well as Closing process groups. However, relax! You do not need to have experience in every process group in every project that you have worked on. You might have joined some project in the middle of the execution phase and thus, might not have been involved in Initiating and Planning phases for the same. Or, you might have moved out of some project midway after initiating and planning for it. In this case, you would not have participated in any ‘Closing’ activity for this project. All this is fine, and perfectly acceptable, provided you have experience on all of these process groups in at least one of your projects.

(2) You must have completed at least 35 hours of Project Management education. You will be required to put in the start date, end date, name of the course provider as well as the name of the training course when filling in the application form. You can go in for training classes conducted by your employer or you may want to attend some online courses. You may also attend some classroom based sessions organized by different training institutes. Only, you should make sure that the course deals with Project Management topics only.? Another option to earn your 35 contact hours with this audio training course.

Remember, you do not need to submit any proofs of your experience or educational qualifications at the time of submitting your application for the exam. In fact, you might not have to submit these documents at all. The only time you will have to produce documentary proof of your education and experience is if your application gets selected for an audit. But it is always advisable to have documentary proof of your experience and educational qualifications in place, just in case they are needed.

Another important thing to remember is that you should fill in your examination form only after you have attained PMI membership. This makes sense not only because you get access to additional study materials but also financially. If you apply for the exam without becoming a PMI member, you need to pay USD 555. However, if you become a PMI member and then apply for the exam, you pay $129 for the membership, in addition to the USD 405 examination fees. The latter amounts to a total of USD 534. So, which option would you go in for? I would prefer becoming a PMP member first, any day. However, make sure that you apply for your exam within one year of becoming a PMI member, otherwise your membership would lapse and you would again have to pay the whole amount of USD 555 for apearing in the exam.

So, get set and be ready to appear in your PMP exam!

Successful Projects: It’s Not Rocket Science

Project Management is not rocket science

Project Management is not rocket science

There is no worse person to be than the project manager at the end of a failed project. As an IT project manager, I have experienced that feeling and I can tell you it’s not nice. IT projects are particularly difficult to manage. In fact there really aren’t any IT projects, just projects that have elements of IT in them.

The trouble with these projects is that often you are doing something that hasn’t been done before, is unproven or cutting edge. Customers expect a good result not excuses, even though these projects are frequently a journey into the unknown. If we take the construction industry, building a new bridge for instance, we have been building bridges for hundreds of years and know how to do it. We understand how things are going to happen, in what order and the expected result. This is rarely the case with IT projects.

Avoiding the common pitfalls of IT project management is not rocket science, it is simply a case of taking some sensible measures. Identified here are five killer mistakes of project management:

Who Owns the Project?

The Mistake:

The nature of projects is change and change often encounters resistance. People don’t like change so they need to know it is necessary and what benefits it will bring. In order for a project to deliver change it needs the backing of senior management. Without it the project will proceed very slowly. The sponsor (senior management) is the person that drives the change forward and the project is the mechanism for change. A project without support from senior management will struggle.

The Solution:

Make sure you have the top down backing from senior management. There must be direct communication from the sponsor to the stakeholders. The message must be, “we are serious, this thing is going to happen so you are either with us or you are not” and beware those that are not.

Be careful as project manager to make sure the sponsor does not take the project over and become the de-facto project manager.

Getting Users Involved

The Mistake:

Lack of user input and involvement is the recipe for a bad project. This can either be because of the “we know what you want” mentality from the IT department or lack of interest from the customer. Either way it must be avoided.

The Solution:

The IT department must take time to understand the customers requirements before proposing any technical solution. Often IT is blinded by the latest, newest thing available and try to shoehorn the requirements into it. On the other hand, customers must devote the time and effort necessary to ensure a successful project by interacting with the IT department and making sure all requirements have been fully defined. Ensure you have spoken to all stakeholders to gathered their requirements and that they continue to work with you for the duration of the project.

Stopping Scope Creep

The Mistake:

Scope creep is the cause of more project failures than anything else. Not knowing exactly what a project is aiming to deliver or setting off in a fit of enthusiasm but little else, is a recipe for failure.

The Solution:

Ensure that the business case, requirements and scope are clearly defined and documented. Make sure the stakeholders understand them and sign them off. Stick rigidly to the scope and if changes are required then put them through a change management process where they are documented, justified and then agreed.

Managing Expectations

The Mistake:

Often there is an expectation that IT is like a magic wand you wave and suddenly a miracle occurs. During a technology project expectations can inflate to a ridiculous degree. It is the role of the project manager to manage expectations to a sensible level.

The Solution:

One way to avoid this is to break a project into smaller pieces or phases. I equate this to a sausage machine, where you feed in the raw material at one end and out it comes as small, perfectly formed, packages or sausages at the other end. The same can happen with IT projects where you take small packages of requirements and push them through the machine, producing several deliverables over the life of a project. This way you manage expectations by making frequent deliveries to demonstrate what the technology can really deliver. This approach ensures the project delivers to the customers expectations by giving them early visibility of what you are building.

Understanding the Lingo

The Mistake:

Have you ever stood next to a group of IT professionals and wondered what on earth they were talking about. It is like a whole new language and to non-IT people it often is. The pitfall comes when the customer and IT think they are talking the same language when in fact they are not. This leads to a problem when the IT department delivers what they understood the customer wanted and it turns out to be something different.

The Solution:

Communication problems are the hardest to resolve as often it is only looking back that the problem is identified. Regular communication and a close working relationship with the customer will help. What you really need is a person with a foot in both camps. Someone who understands the business and the IT equally well. If you can identify this person make sure you keep hold of them, they are hugely valuable. If you are unable to find this person, the next best option is to have two people, one from the business and one from IT. By working closely together and sharing information they can minimise any communication problems.

Finally

In 1995 The Standish Group surveyed IT executive managers for their opinions about why projects succeed. The three major reasons given that a project will succeed are user involvement, executive management support, and a clear statement of requirements. Concentrating on these three aspects alone will give your project a good chance of success.

Don’t become the victim of a failed project, put measures in place that will ensure your success. After all it’s not rocket science!

Read more about IT Project Management

Requirements Management Please!

Developers everywhere are in terrible pain. Why has it come to this? What can we do to make the world a better place for software developers and their children?

This sobering video clip was put together by devshop, and it has me fired up to help these poor souls! So, what can project managers do about these important issues? Let’s take a shot at them.? This post is part of a series, addressing each of the pain points from the video.

Pain #1

We're 4 months in to a 5 month schedule and I just received the final requirements yesterday (and they've changed again!)

Requirements management please! This poor soul desperately needed a good business analyst or project manager a long time ago to flesh out the requirements in advance. Even in an iterative approach, the high-level requirements should be clear before any developer starts coding.

In my experience, project teams are very productive when you have a business analyst or project manager who knows enough about the actual work being done by the project team (usually used to do it themselves) that they can completely free up the team to work on tasks.? Optimally, the team trusts the BA or PM to get the customer needs well defined, and elicit requirements in such a way that most of the normally unstated desires and ideas are captured.

Visuals are great when it comes to this.? Personally, I have taken the approach of using visual tools like modified use case scenario diagrams, GUI mock-ups (for software) and simple functionality graphics to understand and capture user needs (usually creating these on the fly with a projector and the stakeholders in the room, this way you get instant feedback, check for understanding, etc.)? I can use the output from this process (in addition to more formal documented requirements) to help the project team understand what is required, and often I am able to provide visual representations of suggestions for how things might work at a high level (high-level ERD’s for database structure, an outline for documents, etc.)

Furthermore, eliciting quality requirements is an art form, and is best done by a specialist. There are many schools of thoughts on gathering requirements, but the point is that you want someone who really cares about good requirements to be doing it. Many of the project team members are simply too busy with their own work to put much focus on this. I wrote about how good requirements ARE SORTA NUTS earlier, if you want to check it out.

Reverse-Engineering Requirements?

Fellow blogger Craig Brown over at Better Projects asked “Why reverse engineer requirements?” in a recent post.

Interesting question…? Craig asked what value there is in trying to derive requirements based on an existing system.? There are two points that came to mind on this.

  1. If formal requirements were not captured when the current system was designed, and you are about to do another project to build something similar, this might come in handy.? Personally, I would rather start with a functionality description, etc. as reference material and start the actual requirements gathering almost from scratch.
  2. When I gather requirements, I find it very useful to do a simplified set of use case scenario diagrams to capture high-level needs.? They can also be very useful for mapping out the processes that relate to and/or interface with a given system.? If I were building a new system similar to something that is already in use (and there were no documented requirements from the last build) I would construct use cases with the users to document how their needs are fulfilled today.? In fact, I have done this in the past more than a few times.? Note that the existing system may have functionality that is obsolete or unnecessary, and so I would not want to incorporate those features into the new product.? If you derive requirements from a design specification, you may spend time building stuff people won’t use anyway.? The root of all requirements must be the stakeholders who will “have a stake” in the product when you are finished.

Great post Craig, a very stimulating question!

project management basics

Lessons Learned from Anita Wotiz

Anita Wotiz is the guest blogger this week over at the UCSC Extension in Silicon Valley Project Management blog. She published great post titled “An unrepeatable success?” Read it here.

It was great to hear about the project, specifically the lessons learned and trying to relate them to my own experience.

I wouldn’t write the first set of factors off as things that can’t be duplicated. Sure, it’s easier in some cases because these things fall into your lap, but these can be influenced to some extent. Paraphrased:

  1. Good team (competent, cooperative) –A PM can sometimes influence who works on their project, and ensure they are competent. Cooperation and team spirit is largely influenced by the PM, in my experience.
  2. Exciting work –Not every project is glamorous on the face of it, but the PM can and should figure out how to position the product being created to the team by selling them on how much value it will add for the end users, and how their individual and team contributions make it possible.
  3. Full access/utilization of previous work –Again, this usually doesn’t fall in your lap, but it’s amazing to me how many project managers don’t spend enough time during the planning phases trying find previous work that can be re-used. Many seem to want to re-invent the wheel with each project.

As for the other factors, paraphrased:

  1. Don’t constrain the project to a preconceived solution –Three points; I see this so many times, where the sponsor and stakeholders have a preconceived notion of what the solution should look like before they even fully understand the problem! Granted, sometimes there are real constraints that are necessary. I think it’s human nature to start coming up with possible solutions very early in the process, and difficult to avoid. Personally though, I’ve found the best results come from forcing yourself to focus strictly on the need/problem during early planning, including the charter, preliminary scope statement, and initial requirements gathering processes.
  2. Good WBS creation and decomposition, bottom-up estimating –Bingo! This agrees completely with my experience about what helps make a project successful. I’ve had a lot of luck in the past using a delphi-style method of estimating, where we go through each task in a room with the experts who will be performing them, and each person writes down an optimistic, likely, and pessimistic point estimate. I take all the estimate sheets afterwards and roll them together, ask about any outliers, and can usually come up with pretty good ranged estimates with a solid grasp on standard deviation and confidence levels.
  3. Management cost/time buffers available –I agree that it’s critical for the sponsor/customer to realize that buffers are there for a reason…they are not just downtime or waste, they are crucial components of a good project that can handle the inevitable risks that will arise.
  4. Collaboration –It sounds like Anita was able to get the whole team to collaborate on scheduling by using post-it notes on the wall. I think that is excellent, although alternative methods may work just as well to have the team collaborate on schedule and task dependencies.
  5. Iterative Development –This is a benefit I’ve used and seen in my projects too. If you can push out iterative releases that are functional, you can start getting feedback from the customer and make subsequent development based off a real foundation, instead of a theoretical one. Writing code to specs is one thing, but if you can immediately test it against an initial release of the pieces it has to integrate with, you’re way ahead of the game.


project management basics