Requirements Elicitation

Your first responsibility in good requirements management is requirements elicitation and we’re going to give you the 411 on how it works. Requirements elicitation is the method for determining the needs of all the customers and users in the project. This is a very important process, and it requires a collaborative effort between the development team and the client. Our new program helps to facilitate requirements elicitation, making it a straightforward process that allows you to easily organize and prioritize important information.
One thing to keep in mind about requirements elicitation is that it isn’t necessarily just a matter of asking the customer what they want. You have to dig deeper than that, read between the lines, and learn to use your own expertise to understand what they truly need. It’s sort of like when you take your broken-down car to a mechanic. He doesn’t ask if you want him to replace this part or tighten that screw. All he has to know is that you need the car to run – he’ll figure out the rest. So, when you’re meeting with a client, don’t just ask “What do you want?” Instead, ask “What do you need to do?” That way, your client will tell you what they ultimately need to accomplish, and you can help them find the best way to make that happen.
“Why?” is another important question to have in your arsenal. As the customer presents his requirements, don’t be afraid to ask “Why?” when appropriate. Chances are it will help lead the development team and the client to a better understanding of both the problem and the solution.
Take care to learn as much as you can about the client’s current processes. What don’t they like about it now? What do they want to see improve? And don’t just write down what they say and leave it at that. Create a conversation with your client, with lots of give and take. Suggest ideas that come to you on the fly and get their feedback on those ideas.
You should review the full client vision, including future goals and tangential projects, and interview the client stakeholders to get the full set of requirements.

There are often very important unstated requirements that are uncovered and are essential for the project to meet its objectives. As a result the project will meet the written requirements but will not be a success, as the client will be dissatisfied because it doesn’t fit the full vision the client have but didn’t elucidate.

A good way to confirm that you really get when the client means is to write down their requirements and then repeat it back to them for confirmation and to make sure you are correct. Ask more questions to clarify necessary data.

You must attend to the speaker, and then repeat, in your words, what you think the speaker said. This allows the speaker to determine if you really understood. If something is missing, the speaker can further explain the point. Usually when people feel that the other side listens to them, it encourages them to share more details.
When taking requirements notes make eye contact with the speaker, don’t multitask and do other things while listening to the speaker. Do not interrupt the let the other side finish what they say. Clarify the points that you don’t understand, and ask for more details if needed.
Summarize the conversation by organizing the key points and play them back for the speaker.
We are taught that is rude to ask personal questions. People will answer personal questions if they will get them what they want. People will talk all day long about their fears, wants, and frustrations if they feel it will help them to get what they want.

If some requirements or client requests don’t seem reasonable, you should question them. Something that might seem like a simple request from the client may be a huge commitment on our side. We should clarify this to the client and consider the benefit of the request in compared to the cost. Remember, in many cases the client don’t know what is required to develop a feature (this is why they hired you).

Identifying users is another significant component of requirements elicitation, and our program will make that process much easier as well. There are a few different types of users, and the ways in which they differ include: how often they use the product, what features they use, which tasks they perform for their business processes, their level of experience and systems expertise, and their security levels or access privileges. It can be helpful to classify users based on these differences. Keep in mind, though, that some people may belong to more than one class.
Also keep in mind that some users may not even be people. No, robots aren’t taking over the world – yet. I’m just referring to the fact that some applications or hardware components might be interacting with your system, and these could be considered their own class of users.
Other types of users to consider are indirect or secondary users. This group may not be using your application directly, but they might be accessing it through reports or other applications.
Think of as many user classes as you can and build your user class list. Look for groups that have similar needs – those can be considered a major user class with several subclasses.
Once you have determined your user classes, you will want to find user representatives for each class that can provide the voice of the customer throughout the duration of the development process. We’ve found that focus groups comprised of all types of users – both inexperienced and expert alike – are very helpful to the developmental cycle.
Role modeling steps
Use the following steps to identify and select useful set of user roles:
• Brainstorm an initial set of user roles – meet with the client. Each of the participants grabs a stack of cards from a pile placed in the middle of the table. Start with everyone writing role names on cards and then placing them on the table, or pinning them on the wall. When a new role is placed, the author says the name of the new role and nothing more. Since this is a brainstorming session, there is no discussion of the cards or evaluation of the roles. Each person writes as many cards as they can think of. Continue until progress stalls and participants are having hard time thinking up new roles.
At this stage, stick with identifying roles that represent a single user.
• Organize the initial set – now it’s time to organize the roles. Cards a removed around on the wall so that their positions indicate the relationships between the roles. Overlapping roles are placed so that their cards overlap. If the roles overlap a little, overlap the cards a little. If the roles overlap entirely, overlap the cards entirely.
• Consolidate roles – after the roles have been grouped, try to consolidate and condense the roles. Start with cards that are entirely overlapping. The authors of those cards describe what they meant by those role names. Decide if the roles are equivalent. If they are, they can be consolidated into a single role.
You should rip up any role cards for roles that are unimportant to the success of the system. We don’t need user roles for every conceivable user of the system, but we need roles for the ones who can make or break the success of the project.
After consolidating the cards, arrange them on the wall to show relationships between the roles.
• Refine the roles – once we’ve consolidated roles and have a basic understanding of how the roles relate to each other, it is possible to model those roles by defining attributes to each one of them. a role attribute is a fact or useful information about the users who fulfill it. Any information about the user roles that distinguishes one role from another may be used as a role attribute. Here are some examples:
o The frequency with which the user will use the system.
o The user’s level of expertise with the domain.
o The user’s general level of proficiency with computers and software.
o The user’s level of proficiency with the software being developed.
o The user’s general role for using the software.

Serving as an interface between the project’s requirements analyst and the members of each user class are Product Champions. They are vital members of the user communities, collecting requirements from members of the user classes that they represent. Product champs should be enthusiastic supporters of the new system and have a deep understanding of its benefits and its inner workings.
In the event that you are working in a situation where the users are unknown or otherwise difficult to engage, you may have to hire consultants or experts to be surrogates for actual users.
With all of these requirements issues being dealt with, and so many different users and stakeholders in the mix, there are bound to be lots of questions and conflicts arising, right? That’s why you must decide very early on in the project who your decision makers are for requirements issues. When no one is made responsible, then the decisions inevitably fall to the developers, and that really isn’t ideal since they don’t always have the necessary experience, knowledge, and perspective to make the best business decisions. So make sure every group chooses a decision maker right away, and select people who are well-informed on the issues.
For any project, there should always be at least one real user on the client’s team because real users are the ones who know how they need the software to work.
It’s tempting to think that we know what the users want, but no matter how smart we are (and I, for one, am very smart), the reality is that we can’t see the user’s point-of-view, so we really do need their input. Of course we know that sometimes it can be hard to get real users, in which case you need user proxies to represent them. The more user proxies you use, the better, since that makes it more likely that the system you create will meet the needs of a broader range of users.
As you proceed with requirements elicitation, you will find that requirements come from multiple sources, which largely depend on what type of product you’re dealing with. Sources of software requirements include marketing surveys, reports of problems, requests for enhancement of the current system, documents that describe industry standards, documents that describe competing products, events and responses, system requirements specifications, and analysis of user tasks.
During requirements elicitation, you’ll be getting a great deal of the information that you need through user interviews, but there are other simple techniques that you can use as well. Observing users while they interact with software is a great way to gain new insights. Questionnaires are helpful when you want to gather feedback from a large number of users. We’ve also utilized story writing workshops where users, developers, and clients all gather and come up with scenarios, and then ask questions like: “What mistakes might the user make in this instance?” and “What additional information does the user need at this point?”
Requirements elicitation should occur in cycles, with the first round capturing the highest level requirements needed. As the system grows, especially if it is moving in a new direction, you just may find that priorities change or new requirements are revealed. Fortunately our program makes it easy to set and manage these priorities so that your whole team will always be aware of changes.
Both you and the client have a major role in requirements elicitation. The person collecting the requirements, who we sometimes refer to as the analyst, should understand the client’s business vocabulary and become knowledgeable about the client’s business needs and objectives for the system. The information that the analyst collects should be structured into a written software requirements specification, which constitutes an agreement between the developers and the client regarding the qualities, functions, and constraints of the product being built. The analyst is also responsible for explaining the products created from the requirements process.
The customer should also be an active participant, helping the analysts and development team understand his business, taking the time to provide and explain requirements, and describing in detail how they want the end product to function. The customer needs to collaborate with developers in determining priorities, functional requirements, system features, and use cases, providing information in a timely manner and respecting the developer’s cost and feasibility assessments. If the customer requires changes, they should be communicated as soon as possible, following the developer’s process for requirements change requests.
The heart of the matter is that there must be respect and professionalism between all parties involved in the requirements process. If everyone is open to all ideas, prepared to set priorities, honest and fair about costs and impacts, and communicative about needs and changes, then you will be on your way to building the product that the customer desires.
As you can see, this process of requirements elicitation is absolutely crucial because you can’t design a system for your client until you completely understand what problems it needs to solve.
During the requirements elicitation process, you’ll be taking in a lot of info, which should be categorized so that you can document and properly use it when needed. So let’s go over those categories now.
A Business Requirement is anything that describes a financial or business benefit that the customer hopes to gain from the product.
The business requirements represent the top level of the requirement chain. They define the vision and scope for the system. The other requirement types must align with the context and objectives that the business requirements establish.

The scope draws the boundary between what’s in and what’s out. It defines the project’s limitation.

The vision applies to the product as a whole. The scope relates to a specific project that will implement the next increment of the product’s functionality. Scope is more dynamic than vision. It includes the content of each release. The vision includes all the different scopes.

Business requirements describe the primary benefits that the new system will provide to its sponsors, buyers, and users.

Functional Requirements describe behaviors that the system will show under particular conditions, as well as the actions that the system will allow users to take.
User Case and Scenarios are general statements about user goals or business tasks that users must perform. One specific path through a use case is known as a usage scenario. You can find out use cases by asking users what are some of the goals that they have in mind when they’re working with the system.
When a client specifies that only particular user classes may perform an activity under specific conditions, that is what is known as a Business Rule. Business rules are not functional requirements, so you may have to define software functional requirements in order to enforce these rules.
Statements that explain how well the system performs a certain behavior or allows the user to take certain actions are called Quality Attributes.
Then you have Data Definitions, which include definitions of data type, default value, and allowed value.
Constraints are what restrict the developer’s options. Take note of the reasoning behind each constraint so that everyone working on the project knows why it’s important.
And finally there is External Interface Requirements, which describe the connections between your system and everything outside of that system. Whew, that was a long list! But now you have the inside scoop on what requirements elicitation is all about. Obviously it’s an incredibly important process, one that you’re going to want to implement in all your projects right away. You’ll find that our new program streamlines it for you and makes requirements elicitation an absolute breeze.

Requirements Documentation

Now let’s talk about Requirements Documentation. The result of the effort that you put into requirements development is a documented agreement between the customers and the developers about the product that’s going to be built. It’s important that the requirements are fully documented in the way that best captures the process, which is why you want to use software that is specifically designed for requirements documentation.

Software requirements can be represented in a number of different ways. For instance, you can use documents that utilize well-structured, clearly written, natural language; you can use graphical models that illustrate system states, transformational processes, data relationships, logic flows, or object classes; or you can represent the requirements with formal specifications that define features using mathematically precise formal logic languages. Structured natural language, accompanied by graphical models, continues to be the most practical way for the majority of software projects to document their requirements.

As you know, business objectives describe the business problem that’s being resolved – or the business process that’s being improved. You’ll want to summarize the important business benefits that the product will provide in a quantitative and measurable way. State the factors that have the greatest impact on achieving success and specify the measurement criteria to assess whether or not the business objectives have been met.

When the requirement documentation is done, we recommend that you send it out to all of the stakeholders, to let them know what the output of the process will be. Ask them to review it. The truth is, people are always far more committed to making the process successful if they feel they are involved and know the plan.

From a beautiful sports car to the perfect juicy burger, all the finest things in life have certain characteristics that combine to make them great. Excellent requirements have a set of characteristics too. One such characteristic is that they’re Complete. Each requirement needs to fully describe the functionality to be delivered. It’s got to contain all the information necessary for the developer to design and implement that feature.

Another characteristic of excellent requirements is that they are Correct. Each requirement must accurately describe the functionality that needs to be built. The reference should be the source of the requirement or the person who asked for it. It could be a user, for instance. Only users can determine the correctness of user requirements, which is why they should always be involved in the process. Bear in mind that a requirement that conflicts with another requirement is not correct.

Excellent requirements are Feasible. It has to actually be possible to implement each requirement within the known capabilities and limitations of the system. The developers should work with the people that define the requirements to make sure that they’re doable.

Each requirement should be Necessary. Every requirement should be for a feature that the customers really need or are required for compatibility with an external system or regulations.

Excellent requirements are also Prioritized. Assign a priority to each functional requirement to indicate how essential it is to a particular product release. Prioritizing is vital because, if all the requirements are classified as equally important, then it’s hard for the project manager to respond to budget cuts, schedule overruns, new requirements added during development, or other factors that require updates to the development plan.

Requirements should be Unambiguous. Write requirements in simple, concise, and straightforward language so that nobody reading them could possibly misinterpret them. If requirements are not explained precisely and completely, there is the danger that developers will end up trying to fill in the blanks on their own. Requirements that are too ambiguous could also end up creating different expectations on the part of stakeholders, leading to disappointment with the development results.

Requirements should be independent. If a Requirement’s development is dependent on the development of other requirements, it might cause prioritization and planning problems. For example, suppose a customer has selected as high priority a requirement that is dependant on a low priority one. In this case, the low priority feature would have to be developed as well, before developing the high priority feature.
When there is no way to avoid dependencies, you can combine the dependant feature into one larger independent requirement, or find another way of splitting them.

And the last characteristic of excellent requirements? Verifiable. Try devising a few tests or other verification procedures to figure out whether or not the product properly implements each requirement.

There are several requirements attributes that should be recorded during the documentation process. These attributes include: (he numbers them on his fingers)
– Unique ID number
– the date the requirement was created
– its current version number
– the requirement status – such as: Requirements, Design, Development, or Complete
– the origin and source of the requirement
– the requirement type: for example, Mandatory, Optional, or Future version
– the names of the requirement author and the person responsible for ensuring that the requirement is developed successfully.
– the owners of the requirements who will make decisions about proposed changes
– any subsystems to which the requirement is allocated
– a product release number to which the requirement is allocated
– And approval status: That is, Approved, Pending, or Rejected
Other requirements attributes that should be recorded during documentation include:
– The Objective, which is the business objective to which this requirement is related to.
– And also the implementation priority

You have to break down the project into processes, or user stories. Each process represents a sequence of actions that users take to complete a task that will help them to achieve a business objective. For example: In our drapes ecommerce website: one process could be searching for drapes. Another process is selecting drapes and adding them to the shopping cart.

Each process groups a set of features that enable the product user to use the system to complete the task. So you break down each process or story into a list of features. You’ll find that it’s easier to list the features by the order that they’ll be used by the user. For instance, take the process of selecting drapes and adding them to the shopping cart: one feature will be a search engine that enables the user to search for drapes based on criteria like color, size, type of drapes, and fabric. Another feature would be selecting the characteristics of the drapes before adding them to the shopping cart: selecting the color, the size, accessories that can be added to the drapes, and so on.

Once you’ve listed the features of each process, it’s time to start drilling down into each feature. Write a clear description of the way the feature should work and what components it should include, such as buttons, screen layout, field types, value ranges, and so on. The description should be very detailed and very well-organized so that the developers will know exactly what needs to be done. You don’t want to leave anything for them to guess. Usually developers don’t talk to users and clients, so they don’t always fully understand the client needs. If you leave them with too much room for interpretation, then they might take the product in the wrong direction. As a result, the team could end up developing a product that is completely different from what the client expected to get, and then you would need to start the development process all over again or make changes to the product after it has been developed. Obviously that would cost you a great deal of money, waste a lot of time, and leave you with extremely angry clients. So that’s why it is very important to have a clear, detailed, and organized description of how the features should work.

Use simple language, avoid complex sentences, and assume the readers have no basis knowledge of the project. Use consistent terminology, utilizing the same terms throughout the document so that nobody will get confused. If the feature description includes too many items and starts to get too long, you might want to consider dividing it into a few smaller features. The idea is that a feature description should be about a specific functionality. But you want to keep the balance of not going into too much resolution. You don’t define a requirement for every button that you have on the screen. But if a feature includes a few smaller features, each smaller feature has a different role, and requires detailed definition, you should break it into several smaller requirements.

Let’s take for example the shopping cart feature. This is a large part of functionality that should be divided into smaller requirements. For instance: the option to add items to the shopping cart is one requirement. The option to edit or delete items from the shopping cart is another feature. How the shopping cart should be displayed on the screen, with page layout, buttons and fields, is a separate requirement. The payment process is also a feature that we should define independently. So I list the shopping cart requirements under a feature group called Purchasing Process. Each feature in this group will help the user to complete a small part of the purchasing process, until the user can accomplish her business objective of buying the drapes.

Here are three letters you should know: SRS. That stands for Software Requirements Specification. Functional requirements are documented in an SRS, which fully describes the expected behavior of the software system. The SRS also includes non-functional requirements like performance goals and the descriptions of quality attributes. The SRS states the functions and capabilities that a software system must provide and the constraints it must respect. It’s the basis for all subsequent project planning, design, coding, and testing. Customers, the marketing department, sales staff, project managers, the software development team, the testing group, maintenance and support staff, documentation writers, training personnel, legal staff, and subcontractors all rely on the SRS. Needless to say, it’s really important! To document these requirements, you’ll need to use an SRS template, which you can find by clicking on the SRS template below.

Requirements Management software, like Elementool, creates the SRS automatically based on the requirements that you submit to the system. You can even create shorter versions of SRS with a set of a few specific features, in case you want to discuss these features with your team. You do that by simply selecting the features you want to include in the SRS and then the software generates the document for you.

The requirements documentation process isn’t just about writing and recording information. You also have to review the requirements. Any time someone other than the author of a software requirements document examines the product for problems, a peer review takes place. Reviewing requirements documents is a powerful technique for identifying ambiguous or unverifiable requirements. You can also detect bugs in the design during the review process before they are developed. It costs 5 times more to fix a bug at the development stage than in the requirements stage.

There are both formal and informal types of reviews. The informal types include a peer ‘deskcheck’, where you ask a colleague to look over your work product; a ‘passaround’, where you invite several co-workers to look at the document at the same time; and a ‘walkthrough’, where you describe the document and ask for comments on it.

A formal peer review, on the other hand, follows a well-defined process. A formal review produces a report that identifies the material, the reviewers, and the review team’s judgment as to whether the product is acceptable. The review produces a summary of the defects found and the members of a formal review share responsibility for the quality of the review.

Digging deeper into the review process gets us to the inspection process. Any software work product can be inspected, including requirements and design documents, source code, test documentation, and project plans. Inspection is a well-defined multistage process that involves a small team of trained participants who carefully examine a work product for defects and improvements. Participants in the inspection should represent four perspectives: the author of the work product, the author of any predecessor work product or specification for the item being inspected, the people who are responsible for work products that interface with the item being inspected, and the people who will do work based on the item being inspected (such as a developer, tester, or project manager). We recommend limiting the team to no more than six participants.

There are four major roles in the inspection process. The Author creates or maintains the work product being inspected. The Moderator serves as the inspection leader, planning the inspection with the author, coordinating activities, and running the inspection meetings. The Reader paraphrases the SRS one requirement at a time, with the other participants then pointing out potential defects and issues. By stating the requirements in her own words, the reader provides an interpretation that might differ from that held by other inspectors. The final role is the Recorder, who uses an Issue Tracking software to document the issues raised and the defects found during inspection meetings.

The inspection happens in stages, starting with the Planning phase, when the author and moderator plan the inspection together, deciding who should participate, what materials the inspectors need to receive before the inspection meeting, and how many meetings they’ll need to cover the material.

The next stage is the Overview Meeting, in which the author describes the background of the material that will be inspected.

The Preparation stage happens prior to the inspection meeting, and it involves each inspector examining the product to identify possible defects and issues that should be raised. Up to 75% of defects are found during this phase, so keep a sharp eye.

Then it’s time for the Inspection Meeting. During this meeting, the reader leads the other inspectors through the SRS, describing one requirement at a time in his own words. The inspectors bring up possible defects and other issues, while the recorder captures them on a form that becomes the action item list for the author. The purpose of the meeting is to identify as many major defects in the document as possible. The meeting shouldn’t last more than two hours, but if you need more time, schedule another meeting. At the end of the meeting, the team will decide whether or not to accept the requirements document as is, accept the minor revisions, or indicate that major revisions are needed.

The Rework stage is where the author spends time reworking the requirements after the inspection meeting. And Follow-up is the final step, in which the moderator works with the author to ensure that all open issues have been resolved and errors have been corrected. The entire process ends when all of the issues raised during the inspection have been addressed, or any changes in the document have been correctly made, or when the document has been checked into the project’s configuration management system.

To help inspectors look for typical kinds of errors in the products that they inspect, develop a defect checklist for each type of requirements document. This draws the inspectors’ attention to historically frequent problems.

There are a lot of challenges associated with requirements review, and fortunately our program will help make the process much easier. There are a few tips we’d like to pass along to you, though, to help you with other aspects of the process. For instance, we know that large requirements documents, like a several hundred page SRS document, can be seriously daunting. So to avoid overwhelming the inspection team, try performing incremental reviews throughout requirements development. Identify high risk areas that need a careful look, and use informal reviews for less risky material. Definitely consider using several small teams to inspect different portions of the material. Also establish several small teams to inspect the SRS in parallel and combine their defect lists.

And, even if you have a long list of potential participants for requirements inspections, try not to let your inspection team get too large because that complicates things like scheduling meetings and reaching agreement on issues. Make certain that every participant is there to find defects, not to be educated or to protect a political position. Also, we’d recommend that you decline the participation of people who duplicate a perspective that’s already covered.

Finally, we should talk a bit about the project change control process. As requirements evolve and grow during development, projects often exceed their planned schedules and budgets. Frankly, these plans aren’t always based on a realistic understanding of the size and complexity of the requirements. And frequent requirements modifications just make the problem worse. To manage scope creep, you should begin with a clear statement of the project’s business objectives, strategic vision, scope, limitations, success criteria, and expected product usage. Evaluate all proposed changes and requested features against this reference framework.

Creeping requirements include new functionality and changes that are presented after the project requirements have been baselined. The problem is not that requirements change, but that late changes have a big impact on work already performed. If every proposed change is approved, it might appear to project stakeholders that the project will never be completed. It’s kind of like when my husband and I recently re-did our kitchen. There were many times during the process that I thought ‘Oh, maybe it would be nice to also add this on,’ or to change the type of tile along the counter. But for those changes to work, we would have had to start again from scratch. And not only would that have been a pain in the neck, it also wasn’t in our budget.

Of course some requirements evolution is legitimate or unavoidable. We know all too well that business processes, market opportunities, competing products, and technologies can change during the time it takes to develop a product. But uncontrolled scope creep, in which the project continuously incorporates new functionality without adjusting resources, schedule, or quality goals, has a harmful effect. A small modification here, an unexpected enhancement there, and soon the project has no hope of meeting the planned schedule. So you should evaluate every proposed requirement or feature against the business objectives, product vision, and product scope.

The most effective technique for controlling scope creep is being able to simply say no. Philosophies such as ‘The customer is always right’ are fine in the abstract, but you pay a price for them. If you find it difficult to say ‘No,’ try saying ‘Not now’. At some point you have to freeze the requirements for a specific release or you will never complete it.

It’s very rare to define the entire project upfront. There might be outside forces that affect the project during its lifetime. For that reason, change is part of the project. It’s important to have a process in place that’s agreed upon by the client. Change Control is the management of anything that wasn’t in the original scope, requirements, schedule, or cost estimates of the project. It involves updating and maintaining the project documents and the resulting changes to quality, risk, cost, schedule, and so on. Change control includes adding new requirements based on new functionality that is needed, deleting requirements of features that have been canceled, fixing errors in the baseline document, and scheduled changes.

Submitting a change is done by using the ‘Change request’ form. It can be done by using a software form, such as Issue Tracking, that is part of the control management system. A change request should follow a mini-requirements creating process and go through the stages that we described earlier.

The change request should contain the complete snapshot of the change. It needs to include the description of the change, the reason for the change, and an explanation of the benefits to be received from the change. Your Requirements Management software should be able to track all that information. It should also be classified as a new change or a correction to existing requirements. Send the change request over to the development team for analysis, time and cost estimation, and design. Pass it around to all other stakeholders who might be impacted by this particular change. It should then be approved and added to the development plan. When the process is done, be sure to update the requirements records in your Requirements Management software with the changes and notify all teams about the change.

This clip ends the Requirements Management section of the program. Next we are going to learn how to estimate and manage task schedule. Stay tuned.

Product Requirements

Every project begins with requirements.

Although this step is very important, it is often neglected by companies because people see it as a “waste of time.” Both the developers and clients want to get right to writing the software code because then they feel that the project is progressing, but the result of poor requirements is having to make changes to the system later in the project and sometimes even starting the project all over. And this is a waste or precious time, money and resources.

Not defining the project’s requirements and business objectives is considered to be the number one reasons why projects fail.

Clearly, we must learn the requirements before starting the project. In other words, what does the client/customer require? That is the original question upon which the rest of the project hinges. If you don’t know what the customer really wants, then you’ll be managing the wrong project or, just as bad, managing the right project in the wrong manner.

        Many companies trust the client to know what he wants. Unfortunately, clients generally only know what they “think” they want and rarely work through to the end result. One of the most important aspects of project management is getting to the requirements first so that the rest of the project goes smoothly.

       Careful planning, questioning and soliciting are critical to the requirements process, and that is the groundwork we’ll be laying in this first, critical section.

Projects aren’t just comprised of a beginning, a middle and an end but dozens, even hundreds, of working parts. The more “parts” you’re forced to work with, the more challenging the project can be. But if you can nail the requirements before even getting started on the project itself, the challenges you’ll face later will be both less problematic and less frequent.

The Power of Partnerships: Working Together Versus Working Alone

But you don’t have to do it alone anymore. In a period of 18 months myself and the rest of the team at Elementool, Inc. have conducted extensive research, read dozens of books, run surveys, and received a lot of feedback from our clients about their problems in the way they run their projects.

That helped us to gain an understanding of the challenges that companies face and enabled us to come up with a solution that will help companies have control over their project management process. We want to share our knowledge and expertise in the project management field with you to help you improve your life.

We’ll be covering a lot of ground in this book, guiding you through some very important concepts. But one of the best things about Elementool’s Project Management Formula is that you will start noticing results right away. As you begin adopting the practices I show you, you’ll immediately see improvements in your work and life. That’s because the tools are simple, step-by-step and easy to follow:

Six Sections for Success!

What, exactly, will The Project Management Formula give you? What I am offering you in this book are six sections for success, the last of which – the Formula you’ve been hearing so much about – will provide you with the final five steps, or solutions, that will kick your project management into overdrive!

The six major sections that we will be covering in this book are:

  1. Requirements
  2. The Learning Process
  3. Estimating
  4. Time Management
  5. Scheduling and Planning
  6. The Project Management Formula

The first section, Requirements, breaks down the requirements phase for you. This is a crucial part of project management that gets ignored far too often, so I am going to start you off on the right foot by explaining the “why’s” and “how’s” of good requirements management.

That will be followed by our second section, The Learning Process, which I think you will find truly eye-opening. In that lesson, I reveal some little-known truths about how our minds take in information and process change.

Some people think that, to do their job well, they only have to know the technical aspects of how to perform their tasks. But at Elementool we believe that to get to the next level professionally – to find greater success – you need to be able to think beyond the obvious. It’s important to understand how the mind works so that you can create positive changes with your team members and within yourself.

The third section we’ll cover together, Estimating, is where you learn how to create and provide the best possible estimates for your clients and for your team. I will show you different methods for doing this that you will want to put into action right away. Best of all, they are easy to understand and easy to implement.

The book’s fourth section, which focuses on the extremely crucial skill of Time Management, offers a wealth of information and tips on how you can ensure that your valuable time is used to its best advantage.

In the fifth section, Scheduling and Planning, you’re going to find out practical, easily applicable ways to schedule your projects and keep them on track as you go along. You will also discover in this section that good project management involves managing expectations.

Finally, in the last and most pivotal section of the book, I’m going to teach you The Project Management Formula. This is an easy 5-step system for running projects that we here at Elementool are really excited about, and that you will be able to start using straight away. The five steps of “the Formula” are:

  • Step 1: Define project objectives and collect requirements
  • Step 2: Define the priority of the requirements and features
  • Step 3: Planning iterations
  • Step 4: Running iterations
  • Step 5: Present the product to the client

Instant Messaging

Instant messaging has become common in our daily routine. So we have decided to offer it as part of Elementool to help you improve your communication with your team members. Especially if they are located someplace else.

To start a new conversation using the Instant Messenger, please follow these steps:

• Click on the ‘number of users’ online link at the top of the page to display who is currently logged in to the account.
• Click on the name of the user to start an Instant Message session.
• The Messenger window will be displayed on your screen.
• Type your message and click on the keyboard Enter button to send it.

When someone starts a new conversation with you, you will see a red flag next to the ‘number of users’ link.
Follow these steps to join an instant message session:

• Click on the ‘number of users’ online link at the top of the page.
• The person who sent you the message will be marked on the user list.
• Click on the user’s name to open the messenger window.
• Type your reply in the text box and click on the keyboard Enter button to send it.

As you can see, Instant Messaging is easy and can make the communication with your team faster and more efficient.

How to Create Agile Project Schedule

In this clip I’m going to show you how to create an agile project schedule.
As you know, in agile development we take the project and divide it into mini projects called Sprints.




There are many advantages to using the agile method of sprints. A few major ones are:

• Agile development gives you better control over the project – when you run a project, there can be many factors that you need to control. Such as resources, tasks, clients, etc. The more variables there are, the greater the changes are that something will go wrong. Dividing the projects into sprints, gives you better control over the project process since the sprints are shorter and require you to worry about a limited number of factors.
• It makes it easy to keep the project on schedule – if your project is a few months, or a year long, it makes it harder to estimate the project’s schedule. Who can predict what might happen 6 months from now? When you divide the project into short sprints, you only need to schedule one or two sprints at a time. This means that the estimation period is much shorter and more accurate.
• Agile development also helps keeping your clients happy – this is something many people are unaware of. While you work on the project, your clients wait to see results. If the project is long and the clients don’t see results for a period of several months, they start to worry whether things go according to plan. They also sometimes forget why they ordered the project in the first place and might change their mind about it.
When you develop the project in sprints. Each sprint is a mini project. At the end of the sprint, you release it to the clients. This shows them that the project moves forward and keeps them in the loop. They are likely to get less nervous about the schedule and be more committed to it.

OK, now let me show you how you build an agile project schedule.

The first step is to divide the project into workable tasks and submit them to your Issue Tracking account as separate issues.

Then go to Scheduling and click on Edit Schedule to build the project schedule.
The first step is defining a project.
• Click on the Add button and choose the Project option.
• Type the project name.
• The project’s description and start and end date are optional. The system will automatically update the start and end date based on the schedule.
• Click Save.

Now that we have a project, the next step is to define the sprints.
The sprint length is determined based on the project’s length. For example, if the project is 12 months long, the sprints should be between 1-3 months each. On the other hand, the sprints should not be too short. They should be long enough to be considered as a small project.

Click on the + button next to the project’s name.
Choose the option Sprint.
Type the Sprint’s name.
The third step is to add the tasks that should be completed as part of the sprint.
These are the actual work that will be done as part of the sprint.
Click on the + button next to the sprint name and choose the option Issue to add an issue from the Issue Tracking account.
Select the account name and type the issue number. When done click on Save.

Repeat this until all the issues are added to the project.
The final step of building the agile project schedule is to define the estimated time for each issue in the sprint.
Use the Start and End date fields to define the schedule.

As you can see, the schedule of the first sprint is set.
You can repeat these steps to add additional projects and sprints to your project plan.

That’s all for now.

If you already have an Issue Tracking account, you can add Scheduling to your account for only $29.99/month by going to “Control Panel”, clicking on “Edit Accounts”, then clicking on “Manage Account List”, changing the Scheduling package to Premium and clicking on the Update button.

If you still don’t have an Elementool account, click on the ‘Sign Up Now’ button below to open a free trial account.

Do You Have an ETA?

Visibility is one of the main reasons why projects fail. It means that the project manager doesn’t have a full picture of the project’s progress at any given moment.

 

 

 

When you have full visibility, you’re able to stop bottle necks in your project’s progress. This allows you to make changes to the project plan and find ways to solve these bottle necks before it is too late.

I would like to introduce a new feature, The ‘Task Completion Date’ that will allow you to know at any given moment what the status of your project is, and when tasks are going to be completed, by integrating Elementool’s Issue Tracking and Scheduling.

As you remember from our previous clips, you can use Elementool’s Scheduling to define the project’s schedule and the start and end date of each issue that is assigned to the team members.

You can watch the clips called ‘How to Create Project Schedule’ on our blog for more details on how to build the project schedule.

The team members can submit the time that they spend on the tasks in Elementool’s scheduling and this enables you to see the development progress of each task.

I explained how to do that in a recent clip called ‘Track Time Spent on Tasks’.

Now I’m getting to the new feature that we just added:

When a user works on an issue, they can define the estimated completion date on the issue itself, by submitting the completion date in the Priority List section.
The Completion Date is also being displayed on the Scheduling Gantt chart.
When you look at the chart, you can see the issues that are part of the project, their start and end date, and the dark blue bar shows you the actual development progress of each issue. The border of the progress bar represents the estimated completion date of each issue.

By looking at Gantt chart, you can tell within seconds the development progress and the estimated completion date of each issue.
That gives you full visibility of your project development progress and allows you to know if things start to get off track, and make changes to the project to keep it on schedule.

Isn’t that cool?

If you already have an Issue Tracking account, you can add Scheduling to your account for only $29.99/month by going to “Control Panel”, clicking on “Edit Accounts”, then clicking on “Manage Account List”, changing the Scheduling package to Premium and clicking on the Update button.
If you still don’t have an Elementool account, click on the ‘Sign Up Now’ button below to open a free trial account.

 

 

Track Time Spent on Tasks

In this clip I’ll show you how you can use Elementool to track the time that team members spend on issues.
Tracking time enables you to view the progress of the project and make changes to the project plan if needed.
It is also useful for billing in case clients pay you by the hours you spent developing their projects.

To start using this feature, you should have the Issue Tracking and Scheduling services, because time tracking is done using the integration between Issue Tracking and Scheduling.

The first step is to submit the issues to the Issue Tracking account and assigned them to your team members.
I’m guessing you already know how to do that. If not, please see the Issue Tracking User Manual clip for instructions.

The next step is to assign the issues to a project or projects in the Scheduling service.
To do that, please follow these steps:
• Switch to Scheduling.
• Click on Edit Schedule
• Click on the Add button to add a project. You can assign issues to one or more projects.
• Now that the project is defined, click on the Add button to add the issues to the project.

After the issues have been added to the project, the team members can use the Scheduling section on the Issue form to submit the time that they spend on the issues.

To submit the time spent on an issue, please follow these steps:
• Open the issue
• Scroll down to the Scheduling section
• Submit the date and time that you spent working on the issue.
• Click on the Update

If we go back to Scheduling and look at the Gantt chart, we can see the project plan displayed in light blue and the actual time that the team spent on the issues in dark blue. This gives us a quick view of the project progress.

If you still don’t have an Elementool account, click on the ‘Sign Up Now’ button below to open a free trial account.

How to Send Daily Reports

Hi, it’s Allison again.
Today I would like to present two new features that we added to the reporting section:

• The option to define the view type of the Quick Reports.
• The option to automatically send a daily report by email.

The reports offer 5 view types:
• Normal – this is the standard report type that is display on your browser.
• Dynamic – The Dynamic view type enables you to make changes to the issues directly on the report. This allows you to update multiple issues in a single update instead of opening each issue separately.
• Print View – this is a printer friendly view of the report, that is useful in case you wish to print the report.
• Excel CSV and Excel HTML – these two view types enable you to export the report to an Excel file. Each offers a different Excel formatting option and you can choose the one that suits you the most.

We added an option to define the view type of each Quick Report. It saves you the trouble of defining how you would like the report to look like when running it.

Please follow these steps to change the view type of an existing report:
• Select the report from the Quick Report list.
• Click on Edit Selected Report.
• The Quick Report setup window will open.
• Click on the Step 3 button and the on the Step 4 button to go to the Step 4 page.
• On this page define the View Type and click on Save.

The Send Daily Report option enables you to send reports on a daily basis to other Elementool users or to external people who don’t use Elementool.
It is an easy way to send updates about tasks and issues that you have in your account.

For example: every morning you can send a report of all the open issues in your account, to inform people of the tasks that need to be taken care of.

To setup an automatic daily report, please follow these simple steps:
1. Go to the report page by clicking on Issue Report.
2. Select a report from the Quick Report list.
3. Click on Send Selected Report.
4. Define the recipients by selecting Elementool users or by typing email addresses of external people.
5. Check off the ‘Send report automatically daily’ check box.
6. Select the time when you would like to report to be sent daily.
7. Click on Send.

Very easy.

We plan to release more new features in the near future.
Stay tuned!

How to Submit Issues Faster

Hi, I’m Allison, and I’d like to tell you about new options that we added to the Field Dependency feature. This is a very helpful feature that allows you to quickly locate and select relevant information when filling out a form.

The Field Dependency feature enables the creation of relationships between fields in such a way that a dependant field’s value list is determined based on a value selected in the source list.

For instance, let’s say that you have two fields on a form: State and City. The State field lists all 50 states in the U.S., and the City field lists the 10 largest cities in each of those states. Currently, without using Field Dependency, the State field list shows all 50 states and the City field displays a long list of 500 cities in those states. So if a user wants to choose their city from that list, they need to scan through all 500 to find the one they want.

However, by using the Field Dependency feature, the process becomes much easier. It allows the person to first select their state in the State field. At that point, the Dependency rule automatically filters the city list so that the City field only displays the 10 cities from the selected state. This means that the user can simply select the appropriate city from the list of 10 rather than poring through a long list of 500.

To access the Field Dependency feature, you should go to Control Panel, click on Edit Issue Form and then click on ‘Edit Dependencies’.

Click on Add New Rule to add a new rule.

In Step 1, select the source field that triggers the Dependency rule.
In our example it was the State field.

In Step 2, select the target field that is being changed based on the rule.
In our example it was the City field.

In Step 3, define the rules.
For example:
Select State = New York.
Select cities in New York State.

Click on the Add button to save the rule.

You can repeat these steps to create additional rules for these fields.
When you’re done, click on the Save button to save the rule.

We added two new options to the Field Dependency feature:
• The ability to make a field required based on the value of a certain field.
• The ability to hide fields based on the value of a certain field.

Let me explain how these new options work:

The first option enables you to make fields required based on a value of another field.
For example:
I would like to make the City field required when selecting a State value to make sure that when a person fills out the form and selects a State, they also select the city.

To define the city as a required field, move it to the Required Fields list on the Dependency setup form.

The second option is to hide fields based on a Dependency rule.

For example:

I have a field on the form called Country with a list of country names.
When a person selects a State, they should not select Country. To prevent the person from selecting the Country, I hide the Country field when a state is selected.

To define this rule drag the Country field to the Hidden Fields list.

As you can see, the Field Dependency feature makes filling out and submitting forms much easier and far less time-consuming.