How to Learn and Acquire New Habits

We at Elementool have been happy to share our secrets about how to practice good project management. But we also recognize that there is more to your job than just the technical process of managing projects.



Right. That’s why we’d like to take a moment to talk about the process of learning and the process of change. These are big ideas that affect the way you perform as a project manager, so they’re really worth exploring on their own.

When you’re managing a project, you are always adapting to new changes as they come along. On a larger scale, you also frequently have to make changes in the way that you and your team function on a regular basis – and you may find that some people on your team resist those changes, no matter how logically you explain the benefits of that change.
Even if you force them to implement changes, if they don’t truly accept the importance of the change, it’s likely that they’ll resist and eventually go back to their old habits. Making lasting changes can take a lot of time and persistence, and it requires genuine commitment on the part of your team.
This program itself is going to bring changes to your work and your life as you implement the ideas we’ve been talking about. You’re learning new techniques and methods that will create changes in the way you run your projects.

But change can be difficult, and we know that the idea of making so many changes may seem overwhelming. It might even be tempting to think, ‘Well, my current system works fairly well, so I don’t really have to make changes.’ Or maybe you’re thinking, ‘I’d like to make changes, but I’m just too busy working on all these projects to actually do it.’
But don’t let yourself get bogged down in that kind of thinking. Learning new things and making changes can be a positive force in your life.
Part of the trick is just understanding how we learn and change. It’s helpful to know how our minds take on these vital processes.

Take the learning curve. When we imagine a learning curve, we usually think of an image that shows a slow beginning as we attempt to learn, followed by a steep acceleration in success, then finally a plateau at the performance level that we are trying to reach. This leads us to expect rapid changes. This happens often, where people start learning something new, assuming the learning process will move fast, as the curve suggests. But then, when things don’t progress at the rate they expected, they feel a little stuck. As a result, they get discouraged and give up.

That’s why you need to understand that the actual learning curve looks a bit different. Imagine looking at the traditional learning curve through a magnifying glass. What you’ll see is a much more staggered and complex process. You make some improvement as you learn the new skill, followed by a slight decline, leading to a plateau that is higher than the point where you started. The skill improvement, decline, and plateau might vary from one step to the next, but this process will continue gradually upward until you have finally mastered the new skill.
So what is the reason for this process? Well, when we have a skill, we perform it using the habitual part of our brain. That skill becomes a habit, and the subconscious brain is in charge of executing the task. This means that we are able to perform the task without even thinking about it. An example of this that almost everyone can relate to is driving a car. Once you have learned to drive and become experienced, you don’t even think about it anymore. The action is performed almost subconsciously, allowing you to do other things while you drive, like talking to the other passengers in the car, singing along to the radio, or thinking about the day ahead.

When we learn a new skill, we take in new information that allows us to do things that we couldn’t do previously. This is represented by the increase in the learning curve. But, in the beginning, we absolutely must be focused on the task. As we’re learning the new skill, we need to use our conscious cognitive brain – that’s the part that does the thinking. We have to be aware of everything going on around us, and we have to think before taking any kind of action, no matter how small.

If you think back to when you first learned to drive, you’ll probably remember how focused you were on every little aspect of the process. You may have even been a little scared, worrying about getting the sequence just right. Pressing the gas pedal, keeping the steering wheel straight, watching the road signs as you drove along, and making sure to hit the brakes in time. The last thing you wanted to do was turn on the radio or have a conversation with the person next to you because your cognitive brain was too busy focusing on the act of driving.

Even after you’ve become comfortable driving, you’ve probably had the experience of driving in an unfamiliar area. Suddenly you find that you have to shut off distractions like the radio so that you can put your conscious mind on the task of concentrating on turning lanes and street signs as you try to orient yourself in the new environment.

That’s how the learning process works. New information improves our situation by helping us to accomplish things that we couldn’t have done before. This is the rise in the learning curve. But the learning process also requires us to think about and practice the new skill, causing a slight decline in our learning curve. Then, after we have spent some time practicing, the new skill becomes a habit in our subconscious mind and we can do it without thinking. At that point we reach a plateau, which is higher than the place we were before we began the learning process.

This process of learning a new skill might sound difficult, but studies have found that, on average, it only takes 30 days to acquire a new habit. NASA discovered a good example of this many years ago when it used an experimental training program to help astronauts deal with the disorienting effects of space travel. The astronauts in the experiment wore glasses that turned everything upside down, and they wore those glasses day and night for 30 days straight. Then, a totally unexpected phenomenon occurred. After Day 30, the brain re-programmed itself and flipped everything right side up again! They did the experiment again with a few changes, asking some astronauts to take the glasses off on Day 14 and put them back on again on Day 15. But those who had removed the classes had to start over again. Their brains only flipped the image after 30 consecutive days.

That just goes to show that 30 is the magic number when it comes to learning a new habit. The habit comes through practice and repetition, so you must repeat the new behavior each day for 30 days for it to get locked into your brain. After 30 days of regular practice, you’ll find that the new skill has become a part of you.
This applies to the skills and practices that you’re learning from Elementool. Focus on one thing that you’ve learned in this program and do it every day for 30 days. Once you’re sure that it’s become a habit, take another lesson and practice it for 30 days. Repeat the process with each new lesson that you learn. The truth is, you can’t learn everything in one day. Concentrate instead on moving one step at a time and engaging in a lot of repetition. Make it your goal to turn new skills into good habits.

For example, you’re going to learn several different topics in this program: requirements management, estimating, scheduling, and so on. Don’t try to implement everything at once. Pick a subject, like an estimating technique, and use this technique for 30 days for every task that your team runs. Once you feel that you got it, and you start seeing good results out of this change, pick another topic, like a scheduling technique, and use it for 30 days. Then move on to the next subject.

We’re not saying it’s always easy. Look, we’ve all made that New Year’s resolution that we were so excited about, so determined to keep, only to backslide weeks – maybe even days – later. It’s human nature. We’re biologically programmed to resist change. It’s called homeostasis, and it’s actually a pretty good mechanism for protecting us and helping to keep our lives stable. But sometimes it also works against us when we’re trying to make a positive change. That’s why people have such a hard time getting rid of bad habits.
The question is, then: How do we overcome homeostasis when we want to make a good change? First, you need to understand how it works. Expect resistance to change from yourself and from the people around you. Second, be willing to negotiate the resistance to change. When you feel that resistance, don’t fight it, but don’t back off. Instead, accept and negotiate. Be prepared to take one step back for every two steps forward.

Third, find people who will help you get through the process. Find people on your team that will join you for the ride, so that you can support each other, share your experiences, and get advice. The fourth step is to create the change process through routine activities. By integrating these activities into your daily work, it will become much easier for you to practice the new skills that you’re learning.

There are three main factors that might speed up or slow down this change process: The change agent, the culture, and the people. The change agent can simply be described as the person who starts the change process – this can be anyone, and a lack of power on their part is no excuse for not taking the initiative.
The culture refers to the environment that the change is taking place in, and it can have a major impact on the speed of the innovation-decision process. If the culture is supportive of new ideas and change, and everyone is prepared to help with the change effort, then the process will be much faster and easier. Ideally, the culture will also allow for time to learn and adjust to change, understanding that failures often happen on the way to success. And the culture must let people know that it is okay to fail. Unfortunately there is often limited time available to spend learning new processes that would actually increase efficiency – but the fact is that change can’t happen without patience and an investment of time.
The people involved in the change process are also a significant factor in its success, and every person reacts differently to change. Some will accept it right away, but most are slow to change. They often cause problems in this process because people tend to make decisions based on emotions, then justify them with facts. It’s not that people resist the change itself so much; it’s that they resist being changed. Most people handle change much better if they are actually involved in the process and feel some sense of control over it.

Given these factors, you should always introduce new ideas gradually, accepting that it’s a learn-as-you-go process. We suggest that you start slow, be patient, and allow plenty of time for changes to take place. Don’t just throw out the way you currently do everything and replace it with a whole new process. A better strategy is to implement gradual, experimental changes to see if the new ideas are actually able to improve the current process.

And be sure to celebrate the small successes along the way. It’s a good way of encouraging the team to continue with the change process.
Whatever you do, don’t try to do everything yourself, even though it may be very tempting to you go-getter types. And you know who you are. (looks at Allison)
Guilty as charged.

Instead, you should bring on as many people as possible to help out. This ensures that everyone feels a sense of ownership over the change process. When people know that their contribution is an important part of the effort, they start to feel like this thing is theirs, and they want to keep it going strong.
Through every step of the change process, you will be interacting with people, so that means you need to communicate. Everyone will want to know what’s in it for them. Help them understand how the change will be useful in solving their particular problems.

Now that you’ve learned a bit more about the process of learning, we hope you’re ready to take on a lot of exciting new changes.
Just remember: Be patient, be persistent, and you’ll be fine.

Goodbye until next time!

Issue Tracking with Unlimited Fields

In this clip I’m going to introduce you to Elementool full issue form customization.
Everyone who develops projects has specific needs and processes for running the software development. That’s why it is important to choose an Issue Tracking that gives you the flexibility and customization to allow you to fit it to your unique needs.

Elementool’s Issue Tracking offers you full customization of the issue form.
This includes defining the positions of the fields on the issue form and using different field types, as well as the option to add unlimited fields to the system.

Now let’s go into a bit more detail about each option:

First, you should login to the account as an administrator.
Click on Control Panel.
Click on Edit Issue Form.
Click on Edit Fields.

The Issue form is divided into field containers.
Each field container can contain fields.
As you can see, there are different types of field containers.
Some enable you to display large and wide text fields.
Some enable you to display short fields.
You can change the position of the fields by dragging and dropping them around the form in the different containers.

Elementool Issue Tracking offers a selection of 15 different field types.
For example: Text field, dropdown, date, URL, etc.
The tool box on the left top corner of the Edit Issue Form page displays the different field types that you can choose from.

To add a field to the issue form, simply click on it on the toolbox, hold down the mouse button, and drag it to the form to the position where you would like it to be displayed.

Very simple, right?

As I mentioned before, Elementool Issue Tracking allows you to use an unlimited number of fields on the form. This means that you can add as many fields as you wish.
Isn’t that awesome?

That’s it for now, but
I’ll be back soon with more great tips.

All You Need to Know About Requirements Management

Requirements Management is one of the most critical stages in the success of projects.
71% of software projects fail because of errors and oversights made during the requirements phase.

In the following clips we will show you all you need to know about requirements management to help you prevent project failure and delays.
These are a few of the topics that are covered in the clips:
– How to collect requirements from stakeholders
– How to create user stories and interviews
– How to document the requirements using requirements management software
– How to handle the change requests submitted by stakeholders during the development process
– Tips on how to avoid scope creep and how to make sure everything stays within your control

And much more… You don’t want to miss it!

Hello, my name is Allison, and I would like to welcome you to the project management training program. Thank you for signing up – you will definitely be glad that you did. In fact, not only do I want to thank you, but I really want to congratulate you because you’re now embarking on a new program that is going to help you get to the next level professionally.
Hi, I’m Bob and I want to welcome you aboard as well. Allison and I are going to be teaching you the ropes, guiding you step by step through this amazing new program, and we’ll be telling you a lot of great insider secrets as we go. You’re going to see exactly how easy it is to get started using these tools right away. And once you begin utilizing this program, you’ll find that it makes your work a lot easier, and, as a result, it makes your life a lot better.

What we want to talk about first today is Requirements Management, because that is where every project should begin. Not a lot of people realize this, but up to 71% of all software projects fail because of errors and oversights made during the requirements phase. In fact, I can give you an example from my own life that may sound familiar to some of you: Last month I planned my little girl’s 6th birthday party. I decided it would have a princess theme, so I bought a pink cake and sparkly decorations and princess-themed favors. It looked perfect, if I do say so myself. But when my daughter came downstairs and saw everything, she was sad. She loves animals and she had wanted a zoo theme for her birthday. What was my mistake? Not finding out what my “client” wanted ahead of time.

Just like you need to be attentive to the needs of your family at home, you have to focus on your clients’ needs at work. And, frankly, one of the things that I love about this program is that it makes my work easier so that I actually have more time to spend at home. Requirements management in particular is all about helping you to do your job more efficiently. I’ve been serving as a Project Manager for years and I can tell you from personal experience that one of the most common problems for people in my field is the failure to document and understand the client’s needs, which is Requirements Management 101.

Failure to figure out what the requirements are upfront means trouble. The project vision and scope aren’t clearly defined, requirements aren’t prioritized, developers encounter ambiguities and missing information when coding and start guessing what the client wants. The result is often an unhappy client.
Some studies have shown that for each dollar invested in finding and fixing errors during the requirements phase, you can save as much as $200 later on to correct that same problem after implementation. Think how much you save by catching problems early on! So requirements management is the first, and maybe the most important step in successfully completing a project. Yet many people overlook it completely.

The major benefit of requirements management is that it defines the project and provides a framework that enables the tracking and completing of the project’s progress and objectives.
When you implement requirements management, you see the advantages right away. It helps control project schedule and costs, improves communication between members of your team, allows for faster development, reduces unnecessary rework during the late stages of development, and ultimately increases customer satisfaction. I won’t name any names, but the days before I was in charge, I worked under a few project managers who were lousy at requirements management and it made for a miserable working experience. There was conflict among team members, deadlines weren’t met, and the end product was often all wrong.

Simply put, requirements management makes your job easier and it makes your client happier. And, fortunately, you are about to learn a very easy-to-use formula that is going to help you with that aspect of project management.

In the requirements management section of the program here, we are going to take you through step-by-step and teach you everything you need to know. It’s very simple and we’re going to break it down for you so that you can be using it immediately and start seeing great results right away.

We’ll be covering three main areas in this section: requirements elicitation, requirements documentation, and the change control process. In requirements elicitation, we will teach you how to collect requirements from stakeholders, and we’ll show you how to create user stories and interviews. For requirements documentation, we will explain how you document the requirements using requirements management software and you will learn how to create SRS (or Software Requirement Specification). Then we’ll get to the change control process, where we show you how to handle the change requests submitted by stakeholders during the development process. We will also give you tips on how to avoid scope creep and how to make sure everything stays within your control.
Be aware that the requirements phase isn’t a linear process. There are a number of steps, and you may need to repeat some of them, adding and editing more information along the way.
The first step is Initialization, where you gather requirements from the start-up documents, starting with the information that is available to you. This includes defined project goals and objectives, the identification of stakeholders and users, and identified major constraints and benefits. For this process, it is extremely helpful to use requirements management software, which will give you all the tools you need for listing requirements. You will want to use different categories, such as product and project name, security, environmental, and so forth. You will also want to specify the requirement type as mandatory or optional, and prioritize it as critical, high, medium, or low.

Step 2 involves interviewing the key players to gather more information, drilling down for needs that were not expressed in the initial documents, and clarifying existing requests by establishing important information such as priority level. List and prioritize the stakeholders that you plan to interview based on the importance of information that they can give you for writing the requirements. Keep in mind that there are different levels of interviews. You can interview individual people or a group. You can even do a workshop that involves different teams. You can also just observe how people do their work and build the requirements list based on an analysis of their process. For the interviewers, offer recommendations of books that advise on how to ask questions.
The third step is analysis, which involves collecting the information gathered so far, putting it together, and looking for conflicts or missing details. During this stage, the project manager collects the data that he gathered in the interview phase and starts putting the pieces together. First, he should start with the high level picture and determine what the final solution should look like. Then, he can start breaking down each high level requirement into smaller ones, connecting them, assigning them priority, and determining their level of importance to the project. The project manager should be sure to evaluate the risk factor for each requirement at this time.

Step 4 is Documentation, the point at which you put everything together, clearly written and organized, in a detailed and comprehensive requirements document. The document should place all requirements together in a clear flow from high level down to the lower level. These requirements should be as specific as possible, including classifications such as mandatory, required, and so on. The requirements should be measurable and achievable, so that you can determine if they have been achieved. They should also be results-oriented. Define the expected result of each feature. It is easier to build the requirements in a tree structure, dividing them into categories and sub-categories. Each requirement item should have a title and description, with the description written in a story format.

This is the initial stage of the project, in which people may commit to certain activities and resources. As you probably well know, people have a tendency to forget their commitments or change their minds, so that’s why it is important to document any commitments and responsibilities that have been assigned to different people. You’ll find that this will help prevent confusion and miscommunication in the future. If possible, attach meeting summaries, files, and even signed agreements to the requirements to provide additional proof of decisions that have been made during this phase. It can also be quite helpful to attach graphs, workflow charts, or any other supportive documents that can provide additional information and make the requirement description clearer. You should also document activities that the client is committed to do, such as training, testing, and making their resources available. If you anticipate any misunderstanding along the way, document items that will not be included in the project but might be requested by the client in the future.

Step 5, Review, is about getting agreement from all the stakeholders and setting expectations from the different people involved. All stakeholders should get the written requirements definitions and provide feedback. This will give them a chance to verify that their wants and needs are properly addressed in the document. They’ll be able to see how all the components fit together, providing them with an overall picture. This stage can be done by conducting a meeting with all stakeholders and going over the requirements list, though that method works best if there are a fairly small number of participants in the process. For larger projects involving a number of teams and individuals, it’s better to distribute the documents to everybody and then collect feedback from each team. The teams can have their own internal meetings to discuss the document, then forward their feedback to the project manager.
The sixth step is Baselining, which means setting the requirements as the basis for the development process. Once approved, the requirements should be locked and used as the starting point of the project. If you perform similar types of projects, such as web site building, you can use the first requirements baseline as a template for future projects. Keep in mind that the locked document can be used as a legal tool in the future, in case there are any disagreements with the client regarding the project objective and results. The approved version should be distributed to all interested parties. All approval changes need to be made to this version and tracked using version control.

Verification and Validation is Step 7. Here you monitor the requirements through the project life cycle to make sure that the project is developed according to what they define. During this phase, the project manager ensures that each requirement is addressed and completed as planned. Use a test cases management system to run tests based on the requirements. It’s a very good idea to link the requirements with the tests and bugs that have been found during the testing phase. It’s best to define a priority level to each requirement and build the work plan that makes sure that all high level mandatory requirements are completed before the project is over. Throughout the project process, the project manager should track the completion level of each requirement to make sure that the project objectives are achieved.

The eighth and final step is Change Control. Most projects change after the baseline phase, so you need to control the changes and the affects that they have on other requirements, project phases, budget, and schedule.

The requirements phase obviously involves a lot of information gathering and tracking, but you’ll find that our program makes it a snap. Of course, your active participation in this process is key. We’re very excited to be showing you this new program, and we know you will love it. If you’re anything like me, you are really happy when a program comes along that raises your game. You’re already giving 100% and doing great things, but we’re going to show you how easy it is to get to the next level. Come on, let’s get started!

All You Need to Know About Project Scheduling and Planning

In the following clips we will show you all you need to know about project scheduling.
These are a few of the topics that are covered in the clips:
1. How to define tasks and activities.
2. What task dependencies are.
3. How to use buffers for more accurate schedule.
4. The steps of building a project plan.
5. The main reasons why project schedule fail.
6. Using Agile planning for better project control.
7. Task classifying and prioritizing.
8. How to avoid the 4 most common scheduling mistakes.
9. The right way to monitor the project progress.

And much more… You don’t want to miss it!

Hi, Bob here again.

And me, Allison.

As you know, we here at Elementool have been telling you the ins and outs of project management. We’ve talked about how to get the information you need from your client, how to document it, and how to use our requirements management software to get your project up and running. And I’d like to think that we’ve helped make that process a simple and rewarding one.

Definitely. But the truth is that all that planning and foundation-laying won’t amount to much if you aren’t prepared to properly schedule your project and practice responsible time management.

That’s right. Time management is a key element of good project management, and to manage time, you need a project schedule. The project schedule determines how the project plan is going to work. It clarifies the way that the team will pursue the project’s objectives, and it lays out a timeline showing when the team will accomplish each of its goals.

Using the requirements document, and also figuring in project objectives and priorities, the project manager must build a list of the features needed in order for the project to be successfully completed by the team and resources.

We strongly recommend using scheduling software to manage project schedule data. There are a number of items that you should be certain to have in your final schedule. These include:
– All the various phases in the project’s development cycle
– Activities that the team will perform, the ordering of those activities, and of course resources assigned to those activities
– A measure of the amount of time and effort required to complete activities
– Start and finish dates
– Major milestones

The best project schedules successfully capture the vital actions needed to complete the project, without being bogged down in excessive detail.

Bear in mind that the project plan is a guidance tool, but is never set in stone. Although you want to make the schedule as accurate as possible, the reality is that the ultimate timing, as well as the cost, usually turns out to be different from the initial plan. It’s a bit like when you use your GPS to help guide you to a destination. You know where you’re going, and you’ve already worked out the route you want to take, but traffic, detours, and accidental missed turns are just a few of the problems you might encounter on the way. Fortunately the GPS is there to take those changes into account and recalculate the route for you. You may not end up at your destination exactly when you planned, or the way that you planned, but you will get there.

The project schedule will serve as a guide for your team and resources as they take actions to meet the project’s goals. You need to both track and report everyone’s progress, and then take care to make adjustments as changes or new obstacles arise during the project development.

And remember that it’s the project manager’s role to help clients determine their priorities and to communicate to them how the development team will achieve their goals. The project manager should always keep the lines of communication with the client open, ensuring that the client understands that all new decisions made will have an effect on the project as its being developed.

When all is said and done, managing a project schedule is chiefly about building the development plan, tracking your progress, figuring out what your status is, and making course corrections along the way.

There are a lot of advantages to creating efficient schedules for your projects. First of all, efficient schedules allow for better communication. You’ll see that your team communicates more effectively when they have an efficient schedule to work with, and it also provides a standard in which reporting to the schedule will occur.

Secondly, efficient schedules give the project’s many stakeholders a better understanding of what actions have to be performed in order to finish the work. By clearly outlining the actions that must be completed, the schedule ensures that important activities aren’t forgotten, while also preventing the team for duplicating activities or developing unnecessary activities.

Thirdly, an efficient schedule is one that creates common expectations. For instance, it aids team members in understanding how their work might affect other resources downstream. And because the schedule will make them aware of the tasks they have coming up, the team will be better able to plan their work. Furthermore, the schedule reflects the complexity of the work to be done, giving clients insight that will help them understand why a project takes as long as it does to be completed.

A fourth benefit of efficient scheduling is that it boosts stakeholder confidence by demonstrating that the project is being carefully managed and has a guiding document to help keep all participants on track. This helps alleviate people’s fears that the project is unplanned or veering out-of-control.

To make certain that your project is in fact being carefully managed, you need to practice good time management. Time management begins with activity identification. Identifying activities also helps you figure out how your team will achieve the project’s objectives through their work.

When writing activities, they need to be expressed as actions, meaning that you always want to begin the activity statement with a verb. For instance, you might write: Design the graphics, or create a menu. You want your activities to be descriptive enough that it’s obvious to the reader what has to be done, but don’t go overboard and make it too detailed. When you have completed your activity list, check to make certain you haven’t duplicated any descriptions.

Look over your activities and see if any of them can be broken down into smaller activities. Building a web site, for instance, is an activity, but it’s a pretty big one! You can actually break it up into several more specific activities, such as: Writing the text, designing the buttons, and creating the graphics. However, you don’t want to make the activity list too long, populated with tiny items that only take 10 or 20 minutes to complete. In this case, what you might want to do is make the creation of each page of the web site its own activity.

On the other hand, if, say, writing and coding are each done by different members of the team, you might want to divide the work on each page so that the team members are assigned the activities suited to their skill set. An activity length should be between one day to a week. If you have an activity that is longer than a week, you should check if you can divide it into smaller tasks. Having shorter tasks enables you to have better control over the development progress. It also feels better from the developers point when they are able to complete a task and move on to the next one, rather working on a long task that never ends.

Just a little tip about dealing with activities: An activity is always easier to deal with during project execution and control when there aren’t any more than two or maybe three unique resources assigned to it.

One of the most important methods of time management is the use of milestones. Milestones mark points in time, and they generally represent major events that occur during the project lifecycle. A couple small facts about milestones: They have a duration of zero, and you never assign work effort or resources to them.

What are some examples of milestones, you might be wondering? A significant completion point in a project would be a milestone. An important event occurring in the project plan that needs to be seen by management might be a milestone. Even an event outside the project’s scope that has to be finished before the team is able to start another activity could be a milestone.

This process of organizing activities includes two components for each task: Predecessors, which are activities and milestones occurring before. And successors, which are activities and milestones occurring after. You’ll discover that some activities depend on the completion of a predecessor activity and therefore can’t begin until that predecessor activity is finished. For instance, you might want to surf the web, but you can’t do that until you turn on your computer. This is known as mandatory logic.

Mandatory logic dictates the order in which the work has to be completed, and it’s important to document it as such, to make certain that the project schedule shows the correct timing of all activities.

When describing activities that have a sequence of occurring but don’t absolutely have to happen in a particular order, we use the term Preferred Logic. An example of preferred logic might be, say, brushing and flossing your teeth. You can’t perform those activities at the same time – one has to come before the other. But it doesn’t really matter which order you do them in. Some people like to brush, then floss, and others like to floss then brush. Either way is fine.

There are some activities where these two types of logic don’t apply because the activities in question can actually be done in parallel. Like when my wife and I have family over for dinner and we’re preparing the meal. She can be getting the main course ready while at the same time I’m making the side dishes.

In project scheduling, you should know the different dependency types that exist. There are four types of relationships that you can record into the project schedule. The first is Start to Start, which is a situation where successor activities can’t begin until a predecessor activity begins. However, that doesn’t mean that they are required to begin at the exact same time.

The second is Start to Finish. In this case, the predecessor activity needs to start before the successor activity can be permitted to finish. For instance, you have to start designing your web page’s layout before you can finish the graphic design.

Third, you have Finish to Start. The most common relationships in scheduling, Finish to Start is used as the default in most software scheduling tools. This situation occurs when a predecessor activity has to complete before a successor activity can start.

And then there’s Finish to Finish, which is when one or more subsequent activities can’t finish until a predecessor activity does. An example of Finish to Finish would be someone who is coding a web page and can’t finish the job until he has received the graphics and text from his team members.

There are other kinds of dependencies known as External Dependencies. These are conditions that exist outside the project scope, but have an impact on the schedule nonetheless. A common external dependency issue that arises is when you have to wait for a vital component from a customer before you can begin working on a particular activity in your project.

The project team rarely has control over external dependencies, so the project manager should always monitor them carefully. They can be marked on the project schedule as milestones that are linked to relevant activities.

When establishing your project schedule, you want to be careful to not let it get so complex that it becomes impossible to understand or to manage. To ensure that your project, particularly if it’s a really big project, stays manageable, make certain that the schedule includes the minimum elements needed to do the following: One, define the activities that have to be performed. Two, represent the activities to deliverables as well as timeline phases. And three, represent important events that have to be tracked.

A truly efficient schedule should have no more than three levels, one of which is detailed, and two of which are summary levels. The first level is made up of the high-level stages of a project, like iteration name or project name. Under project level comes the task summary level, which groups tasks that are related to a specific feature. That could be a feature that is divided into smaller tasks, with each task being responsible for the completion of that part of the feature. Under the summary level should be the executable work packets that will start in that phase. These are the actual tasks that the team works on as well as milestone events. These are the tasks that the team has to complete.

Both setting and meeting your end date are key challenges when it comes to scheduling and time management. The defined dependencies between activities and milestones are key in determining an achievable end date for your project. You must start by linking all activities with each other. Include milestone events at the end of any requirement that represents the completion of that deliverable. The last activity in the set of activities ought to link to this milestone.

In some cases, activities from different summary levels may be connected to each other. By the end of dependency definition, all of the activities and milestones should be related to each other with just two exceptions: 1) the activities that can begin right away (that is, the ones with no predecessor). And, 2) the project finish milestone, which is the concluding event in the schedule.

When considering the risk management side of your project planning, be sure to add schedule reserves. No matter how confident you might be in the efficiency of your team, it’s always smart to build a reserve of additional time into your project plan in the event that resource availability problems create delays in your schedule.

You’ll want to consider two types of buffers to add to the schedule. One is the Individual Buffer, where you add a small buffer at the end of each individual activity. The other is a Global Buffer, where you add a lengthier buffer at the very end of the activity chain. Remember in college, when you would stay up till 3am working on a paper that was due the next day?

I have no idea what you’re talking about.

Come on, Allison, I bet even you occasionally left a major project to the last minute.

Okay, maybe once. But just once.

That phenomenon is sometimes called the student syndrome, and it refers to the way people will often only completely apply themselves to a particular task at the last possible moment before it’s due. The reason I mention this is because the student syndrome is a good argument against using Individual Buffers. The idea is that the person doing the task, aware that the buffer exists, will just spend that much more time working on the activity. As Parkinson’s Law puts it, work tends to expand to fill the space of the time available for its completion. As a result, the Individual Buffer becomes fairly pointless.

That’s why we at Elementool favor the idea of using Global Buffers. Adding the schedule contingency at the global level ensures that the buffer time won’t be wasted away at the activity level. The project manager will monitor this global buffer, while making certain that the individual task estimates remain achievable. In order to calculate how much time to add for a buffer, you need to take the risk factors for each task into consideration. Think of what might go wrong and how much extra time it would take to deal with that problem. Estimate a buffer time for each individual task, then add it up to get one large buffer for the end of the project.

When you begin calculating the schedule, you start with what is known as the initial schedule, which represents the combination of task sequence and task duration. The reason we call it the initial schedule is because we haven’t yet taken people and equipment limitations into account. For the next planning step, you’ll use the initial schedule as your starting point, balancing it against the resources that you have available for the project.

When calculating the schedule, create a Gantt chart. The most popular display used for project scheduling, the Gantt chart is noted for its clarity. Some software solutions, like Elementool, create the Gantt chart for you. All you need to do is define the project structure and tasks, and assign duration for each task. Elementool will do the rest.

Now to work out how long it will ultimately take to complete the entire project, you must determine the critical path of the project. The critical path is the longest dependency chain of activities that establishes how long the project will take to finish. To complete the critical path, you must define these three elements: activities, durations, and dependencies. You do this by identifying the path of activities that brings the project from start to finish. You need to add up the duration of each activity to its predecessors. If there are parallel activities, then just select the longest one. Add up these activities, and the sum will tell you the critical path and the length of time it will take for the project to be completed.

Once you’ve built the project plan, you should compare it to the target date previously set by the client. Providing the dates are similar, you can do project analysis and adjustment in order to meet the goal date. However, if there is a pretty big difference between the two dates, we’d strongly recommend that you meet with the client, explain the reason for the discrepancy, and work together on finding a way to narrow that gap.

Assuming that time is the biggest constraint, some solutions you can consider are: bringing in more money in order to procure more resources, or improving resource skill in order to better your team’s overall performance. Altering the schedule structure for the purpose of completing activities in parallel – rather than using a sequenced approach – can also help you finish the project more quickly. Another step to consider is reducing the project scope to basic solution functionality by the client’s needed date, and then providing the remaining functionality later on.

If it turns out, though, that scope or cost are more important constraints, then the client should agree to accept a different end date – either the one that has been calculated by the schedule, or some other date in between.

As you remember from our estimating session, you should resist the temptation to shorten the estimates just to get the project to fit the deadline. Otherwise, you might reach the deadline date too soon, before the project can be completed.

Now we want to start getting into some of the nitty gritty of the planning process. First, I have a few facts for you to think about. Did you know the average project exceeds its schedule by 100%? Or that 65% of projects significantly overrun their cost estimates? And get this – 64% of the features included in products are rarely used or never used at all. Statistics like these are an important reminder that a lot of thought needs to go into project planning.

Planning the schedule is a major process that requires the effort of your entire team. We’d like to share a few brief guidelines that are key secrets to successful planning. First, everybody needs be involved in the process and fully committed to the success of the project. Second, when you’re discussing estimates with the team, be sure that they all understand that estimates can never be completely accurate.

Third, revisit and revise your plans often, using each iteration as a way of judging the project’s progress. Then make changes accordingly. Fourth, track and report progress. Fifth, divide the project’s features into smaller tasks. Sixth, be certain to prioritize each feature.

Now I don’t want to sound like a pessimist …

Uh-oh.

Hear me out. Those are great tips, and each of those steps is important if you want to make and follow-through with a solid project plan. However, planning does fail more often than many project managers would like to admit. So I think it’s worth taking a moment to talk about why those failures happen. That way, we can help you avoid the same fate.

That’s a really good idea, Bob. There are many reasons why planning fails. One of the most common is when people plan by activity rather than by feature. The traditional approach to planning frequently focuses on completing activities rather than on delivering features. This is a big mistake because your client doesn’t get any value from activities being completed. It’s the features, not the activities, that customers value. That’s why planning should always be at the level of features rather than activities.

Very true. A related problem is lateness being passed down through the schedule. Since traditional plans are so often activity-based, they get focused on the dependencies between the various activities. An early start of a later activity demands that you first complete the activities that it’s dependent on. So if any early activities run late, then the rest of the activities that come after it are also going to be late.

Multitasking is another source of planning problems as it often causes delays. Traditionally we think of multitasking as a good thing. If I’m able to put in eight hours at work, take my daughter to a playdate, do the grocery shopping, finish the laundry, catch up on my favorite TV show, and send out a dozen or so emails before bedtime, that’s not half bad, right?

That’s a talent.

In the workplace, though, multitasking can require you to spend quite a bit of time switching from one task to another, especially when you’re trying to remember where you last left off. It’s a process that can actually result in a great deal of wasted time.

Another notable reason for planning failure is when the work outlined in the plan isn’t prioritized by its value to the users and customers. When this is the case, developers will just work on the features in random order. Then, as the end of the project nears, the developers have to start dropping some features in order to make the deadline. Since the high priority features weren’t earmarked to be completed first, they’re in danger of getting dropped.

Refusal to acknowledge uncertainty can lead to serious planning disasters. You shouldn’t just assume that the initial requirements analysis resulted in a complete specification of the project, or that the users won’t come up with new or different needs during the period of the project schedule. Developing the project in short iterations can be helpful in reducing uncertainty. Be sure to show the software to its users and ask for their feedback every few weeks.

One more reason that planning sometimes fails is that the project manager allows the estimate to become an actual commitment. This is an enormous mistake. An estimate is only a probability. Your commitments should be made to dates, not probabilities.

Now that we’ve got the potential pitfalls out of the way, let’s discuss some of the types of plans that you will utilize. Take, for instance, an Agile Plan. As the name indicates, this is a plan that has some wiggle room. An agile plan is a plan that is easy to change. Of course we don’t want to change it for no reason, but we may want to change it because we’ve learned something new along the way.

Just because we might change the plan, though, doesn’t mean that we’re going to change the dates. We want to try to keep the dates intact, but some ways we might change the plan without altering the dates include reducing the scope of a feature, dropping a feature entirely, or adding new people to the project.

As you go into planning, remember that the entire project can’t be defined at the beginning, therefore you can’t do all of the project’s planning at the beginning. Agile planning is usually spread fairly evenly across the project’s duration.

One advantage of agile planning is that it involves frequent planning. At the start of each iteration, an iteration plan is created. After each of a few iterations, the release plan is then updated. Through this process, the team is able to revise and update the project plan based on the actual project, rather than attempting to create the perfect plan at the very start of the project.

Another advantage of agile planning is that it has short cycle times. Each iteration is a mini-project that has its own particular list of features. Clients can share their feedback on the features being developed at the conclusion of each iteration, allowing for a more controlled development process. This keeps the team from wasting time developing unwanted or unneeded features.

The iterations that agile teams work on always end on time even if functionality is dropped. On an agile project, there isn’t an upfront requirements phase, followed by analysis and architectural design, and so on. Instead there is a very short design and modeling period at the beginning of the project. Once the project begins moving forward, then the design, analysis, coding, testing, and other work is done within each iteration.

The agile team turns one or more requirements into coded and tested software during the course of each iteration, so they are regularly making progress on the project by delivering features in each iteration. The product needs to be brought to a potential shippable state at the finish of each iteration. In some cases, one or more iterations complete a set of related functionality, and this is known as a release.

It’s important for agile teams to maintain their focus on business priorities, delivering features in the order laid out by the product owner. You don’t want there to be too many technical dependencies between features, since that can complicate the product owner’s attempt to prioritize features into a release plan. The agile team needs to concentrate on delivering user-valued features, not just completing various isolated tasks.

Because the plan devised at the start of the project doesn’t necessarily dictate how the project will actually go, an agile team needs to inspect and adapt. Technologies fail, people come and go, clients change their minds … who can say what will happen? And each of these changes means that you have to update the plan. So agile teams incorporate any changes and new knowledge learned during the previous iteration at the start of the next one, adapting accordingly.

Release planning is the process of a high level plan which covers a period longer than an iteration. A release, which typically covers 3 to 12 months of development, allows the product manager to determine what is going to be developed and how long it will be before a releasable product is ready. This helps to create expectations and to provide the team with a target to focus on, so that they aren’t simply moving from one iteration to the next.

Planning a release requires you to figure out how much can be accomplished by what date. Sometimes you might start with a date and see how much work can be finished by then. Other times, you might begin with a specified set of features and see how much time it takes to develop them. In the release planning stage, it’s best not to assign tasks to people yet, since at that point there is only general information available about what work needs to be completed.

Before even beginning the release plan, it’s vital that you know what factors will make the project a success or a failure. Ask yourself: What are the business objectives that this project needs to achieve? Once you’ve answered that question, you need to estimate the features. At this point, keep the estimates pretty general – you don’t need to get into every detail in each feature.

Next, decide on the iteration length. Two to four weeks is fairly standard. After that, you should estimate the velocity, or, how much time it will take for the team to complete their tasks. If your team has worked together before, try basing the estimate on previous projects.

If you have a deadline set for the release, you should determine how many iterations can be fit into the deadline. Then, based on the estimates, decide which features can be finished in that time frame. The product owner will choose the high priority items, which will go into the first iteration. You can then distribute the other features into the following iterations, working on the highest priority features down to the lower priority items until the release plan is ready. Be sure to update the release plan regularly, based on how the project is progressing.

Now let’s discuss iteration planning, which will give you a detailed, short-term plan that the team can use to develop the project. An iteration plan is created in a meeting called especially for that purpose, and the meeting should include the product owner, programmers, database engineers, user interface designers, testers, and others involved in the project.

Don’t assign tasks to team members during the iteration planning meeting – wait until the iteration actually begins. At that point you will usually want to assign one or two tasks to each person on the team. Tasks don’t start until previously assigned tasks are finished. Team members should choose tasks based on their availability and the availability of their teammates.

The process of assigning tasks in an iteration is pretty simple. Just remember to start by identifying the business objective. Next you select features that support that business objective. Follow that with breaking the features down into tasks, and estimating those tasks, then defining priorities. Finally, assign tasks to your team.

You’ll want to hold an iteration review meeting to discuss important details about what needs to be accomplished during the iteration. This meeting will likely take around an hour, or as long as a half a day for a really big project that has several teams. After the meeting, the team members should identify what should be accomplished during the iteration, and then.decide on priorities. Once features are broken down into tasks, team members need to estimate each task.

There are four main priority classifications. “Low” means that the feature can either be developed during a major system revision sometime in the future, or it can not be developed at all. “Medium” means that the task should be completed after all serious tasks have been dealt with. “High” tells you that this task should be developed as soon as possible during the normal course of development activity, before the software is released. And “Immediate” means that the tasks needs to be resolved, well, immediately.

Another type of classification for software features is a severity classification, which is based on the degree of the feature’s impact on the project objectives. There are four types of severity classifications, starting with “Low,” meaning that the feature is an aesthetic enhancement or a result of non-conformance to a standard. The “Medium” classification means that the feature doesn’t impair usability, doesn’t interfere in the fluent work of the system and its programs, and it will not cause a failure of meeting the objectives. Classify the task severity as “High” if the task causes the system to produce inconsistent, incorrect, or incomplete results. The severity is “Critical” in cases where the project cannot be considered as successful without this feature.

Bear in mind that part of the iteration will include fixing bugs found during development. Estimates for coding a feature should always include extra time for fixing bugs that might be found in the process. Or you can define a separate task specifically for fixing bugs. Defects that are found later on, not as part of the iteration, can be dealt with the same way as features – prioritize the defects and add them to another iteration.

A task in an iteration that is dedicated to researching and answering a question about the development of a feature is called a Spike. Estimate and add spikes to the plan just as you would any task.

The length of an iteration determines how often the software can be shown to users and customers. We recommend showing them the product at the conclusion of every iteration and asking for their feedback so that you know the project is being developed in a way that meets the client’s business objectives.

If it turns out that they want something added, removed, or changed, it’s much better (and less costly) to do it after just one iteration than at the end of the whole project. Some users will change their minds about a feature once they’ve seen it in action. The feature that seemed like a good solution in theory may turn out not to be so great in reality, so they want to change it.

By the end of the iteration, you can get a sense of how quickly the project is developing, which allows you the opportunity to re-estimate the rest of the project more accurately. The project manager is better able to determine if the project is on track by measuring the progress this way on a regular basis.

As you might expect, shorter projects will have shorter iterations than lengthier projects. For instance, if you’re working on a project scheduled to take only two months, one-month long iterations aren’t going to be very helpful to you, since you’ll already be halfway through the project before you’re able to measure any progress or make adjustments. Having the end of the iteration too far off in the future also reduces the sense of urgency amongst the team members. When iterations are short, it pushes the team to work harder so that they complete their tasks by the end date.

Then again, you don’t want too much pressure on your team. Try to find a good balance when deciding on iteration length. If the iteration end date is unrealistically short, the team will start to feel like the deadline is impossible to meet, which will reduce their morale and their efforts. Also try to keep to the same approximate length for each iteration, since that will give the team a helpful sense of rhythm.

To monitor the iteration plan, you should utilize a task board. This gives the team a way to organize their work and to show how much work is left to accomplish. The task board shows which tasks are part of the iteration, grouped by status. Each row represents a iteration. Tasks are sorted by their priority, with the highest priority tasks displayed higher than the low-priority tasks. The developers may change the estimate of any task at any time, in the event that they have reason to believe a new estimate is in order. Remember that bugs are tasks too, so they should also be added to the board.

Because agile team members are only assigned to tasks when they are actually ready to work on them during each iteration, you will see tasks on the board that are still waiting to be assigned to someone.

So you’ve created your project plan and schedule. Good work! Now you’re done with scheduling, right? Mmm, wrong. Monitoring your progress is crucial to making sure that the schedule is going to plan. By tracking and reporting the process as it goes along, you will be able to note problems and refine the plan as needed.

As project manager, you need to manage two types of reporting: Status Reports, which come to you from the project team via team leaders; and Project Progress Reports, which go from the project to external stakeholders such as the client. Information that you get from the status reports will go into the project progress report.

To make this go smoothly, we advise project managers to develop a process for status reporting that provides accurate and useful information about the project’s progress, but doesn’t require resources to spend an overwhelming amount of time focusing on reporting during their work.

When talking to your team about status reporting, consider how you want your resources to define completion. Often, project managers are too attached to the notion of “percent complete”. But that doesn’t give much information about the amount of work that still has to be completed, at least not until the resource provides unit values. Keep in mind that a truly effective status report ought to ensure that the resources will be able to begin their planned work on time, and report any new status or risks that need to be addressed.

Another method of reporting that you should know about is that of work effort and end date. This method demands a little more work from the resource, but the project manager gets better information from it. This type of reporting should show the total amount of time that was scheduled, how much has already been used, how much remains, and an answer to the question of whether or not the task will be completed on time. You could find that the total number of hours spent is greater than what was planned, yet the work is still finished on time. If that’s the case, the project manager needs to ask how the additional hours will be added to the extra cost or time taken from other tasks.

Burndown charts are a useful way of measuring your team’s progress, and, more to the point, showing you how much still needs to be done. In a release burndown chart, the vertical axis shows how many hours remain in the project, while the horizontal axis shows the iterations. By showing the amount of work that still remains at the start of each iteration, the release burndown chart serves as a good indicator of how quickly the team is reaching its goal.

Iteration burndown charts can be created in the same way as release burndown charts. Iteration burndown charts are also very useful in illustrating how much work still needs to be done. For instance, if you’ve spent 10 hours on a task that was supposed to be finished in 12, and you’ve completed 50% of the task, the fact that you spent 10 hours working on it doesn’t actually tell you much. The more valuable piece of information is the fact that you’ve completed 50% of the task, and the iteration burndown chart makes it easy to see this.

Ultimately, when it comes to tracking and reporting, the project manager needs to find a balance between getting all the details necessary to keep the plan on target, while also taking everybody’s time into consideration.

There’s no question that scheduling can be a tough process, even for the most experienced project managers. Expect to encounter a few bumps in the road along the way. We’ll help you understand some of the challenges you might be facing, and how you can make adjustments to the schedule as needed.

A common mistake that project managers make when it comes to time management is attempting to build the schedule right at the beginning of the project. This is tempting because there is often pressure from the client to know precisely when the project will be finished. The team, too, tends to become focused on what needs to be done to complete the project. But no matter how motivated everyone is to get to the finish line, you need to start by defining the project’s requirements and objectives.

A pretty typical problem that you will come across in scheduling is discovering that you have an over-allocated resource. This is a team member who has been scheduled to work more hours than what they actually have available. There are several ways to deal with this situation.

One solution is to simply leave the over-allocation as scheduled and expect that person to work overtime. Obviously there are downsides to that solution, and they include the higher cost of overtime payments and the additional risk of project delays in the event that the employee is unavailable or already scheduled for overtime. On top of that, permitting a resource to be over-allocated at the baseline is really just bad practice. You should only go this route as a last resort or when you’re trying to get the project back on track, and, even then, expect problems.

Another option is to fix the over-allocation and retain the current schedule timeline by either replacing the current resource with a more productive person who can bring about the same results in less time, or by adding a resource to help out the over-allocated one. The second choice might be more costly, and it may not turn out as you hope if the newbie has a learning curve. In some instances, adding a resource can actually result in it taking longer to complete the activity.

Your last option is to resolve the over-allocation through resource leveling – also known as spreading out. Be aware that if the activity that the resource is working on is on the critical path, this may lengthen the project’s timeline. But if the activity isn’t on the critical path, then spreading out the resource’s work time might not have any effect on the end date of the project.

If it becomes necessary for you to reduce the total length of the project, there is a technique that you can use to adjust the schedule called Duration Compression. Duration Compression is accomplished using one of these two methods: Fast Tracking and Crashing.

Fast Tracking is when dependency logic is removed from the schedule so that activities may be worked on in parallel. But of course some dependencies can’t be removed, since the nature of the work demands sequences. Crashing, on the other hand, involves shortening the duration of one or more activities within the schedule – specifically activities that are on the critical path. There’s no use in crashing activities off the critical path, since that would only increase float without actually lessening the project’s duration. Generally, crashing involves either adding to or replacing resources in a way that results in shorter activity duration.

There are several issues to take in to consideration when crashing. First, which activities are on the critical path? Only consider those that are fixed work or fixed resource tasks. Second, consider cost and ask yourself which of these activities would be most cost effective to add resources and skills to? You may find that some will cost more than others. Third, think about timing. Which of the activities will truly be shortened by adding resources? Fourth, which of the identified activities will experience the least reduction in quality as a result of the added resources? And finally, consider resource availability – which of these activities needs a skill set that is available?

Sometimes you will find that you have to make project plan adjustments, and there are a couple of different methods you can employ to do this. One is Scope Slimming, which can be used when it’s possible to reduce the deliverables of the project with approval, for the purpose of keeping the original date. Remember that Scope Slimming should go through the change control process. There is a possible downside of this method, which is that the final product might not perform as needed to meet the business objectives, therefore resulting in a potentially unhappy client.

Another method is Quality Slimming, which results when you reduce the functionality of the deliverables as a means of keeping the end date. This needs to go through the change control process as well. With Quality Slimming, there is also the possibility that the final product won’t perform as required to meet business objectives.

Well, there you have it. We’ve talked about the process of scheduling, the benefits of creating efficient schedules, techniques for good time management, setting end dates, planning, tracking, overcoming challenges, and a whole lot in between.

We know a process like this can appear daunting at first, but we at Elementool feel very strongly that Scheduling is one of many project management duties that can be easily mastered with a little practice and a lot of great advice.

And we hope that you found our advice – which comes from years of project management experience – helpful. Any parting secrets about scheduling to share, Bob?

Just one. As project manager, you should try to encourage a spirit that says “We’re all in this together,” so that everyone on your team is eager to do their part – even if that sometimes means helping with a task that isn’t in their normal job description. Research has shown that a committed team is one of the keys to a successful project.

That’s so true. So keep up the good work, keep your team motivated, and we’ll see you again soon!

The New Remarks Message Board

Hi I’m Allison.

I would like to introduce our new Remarks Message Board.
As you already know, the Remarks Message Board enables you to submit messages related to the issues in a message board structure.



We are proud to release the new message board that adds more flexibility and options to the way you type your messages.

The new remarks message board includes the following new features:
• An ability to embed images into the remarks message
• An option to insert links to web pages and files.
• Control over the font formatting such as color, bold, background color, etc.

I’m going to show you how each of the new features work.

To embed images in the message please follow these simple steps:
• Click on the Insert Image button.
• Select the image on your computer.
• Click on Open.

To insert link please follow these steps:
• Type the link text in the remark
• Highlight the text
• Click on the Insert Link button
• Choose the link type from the three link options:
Http which is a standard web link
Https is a standard secure web link
File is a link to a file on your computer network
• Type the link location
• Click on Save and the link will be added to the remark

To change the font formatting please follow these steps:
• Highlight the text you wish to format.
• Choose from the formatting options on the toolbar.
• You can also first choose the formatting option and then start typing and the font will be changed accordingly.

When done click on the Update button to submit the remarks.

That’s it for now. We are developing additional new features that are planned to be released in the near future. Stay tuned…

What is The Best Way to Define Task Priority?

It’s Allison here again.
In this clip I’m going to show you how you can improve the efficiency of your project development process so you can develop more in less time.



 

One of the main reasons why projects are late is lack of proper priorities.
It’s very common to see developers working on low priority tasks instead of focusing on the high priority tasks first.

I’ll give you an example:
Let’s say we develop a shopping cart.
The highest priority task would be to develop the credit card payment processing.
A lower priority task would be to develop the page design layout.

Why is credit card processing more important than page design layout?
Because you can’t process the transactions without the payment processing system, but you can process your transactions if the page layout is not done yet. Although, needless to say, it’s much better to have both of the tasks completed.

Another advantage of using priorities is having the ability to control the project schedule and deadline.
If you’re about to reach the project release date and several of the features are not ready yet, it’s much easier to delay low priority tasks to the next version and release the project on time.
But if you haven’t completed the major high priority tasks close to the deadline, you can’t delay them to the next release — and this means that your project couldn’t be released on time.

It’s very common to use priority categorizing such as:
Critical, High, Medium, and Low.

But what if you have 10 high priority tasks? Which one should you finish first?

To try to solve that, people add a second tier of priority. Often it is called Severity.
For example: Critical, High, Medium, and Low.

Using this system, you would first complete issues that are Critical Priority and Critical Severity.
Then you’ll complete issues that are Critical Priority and High Severity.
Starting to get complicated, right?
Furthermore, what if you have five tasks with Critical Priority and High Severity?
Which should you complete first?

I bet you’re pretty confused by now. It’s understandable, because these priority methods are confusing and too complicated.

This is why we developed the Priority List system that makes your life a lot easier.
The priority List enables you to define a unique priority value to each task in a simple manner of using numbers.
This means that an issue with priority value 1 will be developed first.
An issue with priority value 2 will be developed second, and so on.

With Priority List there is no way to get confused.
Each team member knows exactly what they should work on at any time by just looking at the Priority List and simply focusing on the issues based on their order.

Priority List gives the manager full control over the development process.
It’s easy to define and change task priority by simple dragging and dropping them on the list.
It is also possible to see the progress of each task right on the list itself, giving the team leader a full overview of the project progress.

So toss away the old complicated priority system and start using the quick and simple Priority List right away.

If you still don’t have an Elementool account, you should try a free trial by clicking on the Sign Up Now button below.

 

 

What to Look For in Issue Tracking Software?

Hi, I’m Allison.

If you’re viewing this video, you must be looking for an issue tracking tool.
I’d like to help you with that and explain the features that you should look for when choosing issue tracking software.



 

 

Issue tracking is one of the basic tools used for project management and software development.
It is mainly used for task management, bug tracking, and defect tracking.
This is why it’s important to select the right issue tracking software for the success of your projects.

Here are the main features you should look for when selecting an issue tracking tool.

Make sure that the issue tracking software has a dashboard that enables you to view a snapshot of your project. This dashboard should be customizable and should use both text and charts to display details about your issues.
It should allow you to view the issues that are assigned to you and sort issues by their status, such as New, Fixed, Closed, and so on.

Another important feature is file attachment. You should be able to attach files to your issues. It is one of the most common features that developers and testers use when reporting and updating bugs. In many cases it is helpful to attach a screenshot of the bug or a short video that demonstrates how to reproduce the defect. It saves time when a team member views the bug report and helps them to better understand what it is about.

Next is issue reporting. Reporting and search is a very useful feature that is used often. It enables you to display issue reports based on search criteria.
For example, you can display a report of all the open bugs, or all the bugs assigned to a specific developer.
You want to make sure that the reporting feature allows you to easily set different query filters and customize the report display by enabling you to choose the columns that are displayed on the issue report.
Another useful feature is the option to create save report settings by creating a list of quick reports. This way you can select the report from the list and display it with the click of a button instead of creating the report every time from scratch. That’s a big time saver!

Email notification is also a handy feature you should look for when selecting an issue tracking tool. It enables you to send emails to team members when issues are updated. This way you can improve the communication between team members and enable them to respond quickly to bugs that are reported to the system.

These are the basic features you should look for in issue tracking software.

If you still don’t have an issue tracking account, you should try our free trial by clicking on the Sign up button below.

 

 

How to Link Different Parts of The Project Stages

Today I want to explain how to link between different parts of the project stages.

A project is never just one thing. It includes many tasks and items that – if you do everything right – come together to form a single whole and a successful end result.



Upgrade Now!

Each project is performed in stages. You have to first define the requirements of the features that you want to develop over the course of the project. Then you have to break down each requirement into workable tasks. When the tasks are completed and the features have been developed according to the established requirements, you must run test plans to locate any potential bugs. If you find any bugs, you report them for fixing so that you can ensure that the entire project works according to plan.

Clearly this is a complex process and it requires you to keep track a lot of information along the way. And if all that information isn’t tracked correctly, your project can turn into a total mess very quickly. A poorly tracked project means you have a chaotic work situation, frustrated developers, massive delays, and, ultimately, an angry client. Needless to say, you want to avoid a nightmare like that.

To keep a project running smoothly, you want to make sure that every aspect of it is connected. That way, tasks and tests don’t fall through the cracks, get ignored, and create trouble in your development process. The best way for you to keep everything connected is to use Elementool’s record linking feature. Elementool makes it easy for you to link all of the various project components together, so you can track each item along the way.

Now let’s talk about exactly how you utilize Elementool to link those components.

As you know, Elementool offers a full set of tools that helps you run the different stages of the project.
We enable you to write feature descriptions using the Requirement Management system, then you can break down each feature description into workable issues and assign them to your team members. At the same time, you can define the testing plan by using Test Cases to write tests for the different features in your projects.
All these parts are linked together.

Let’s say for example that we build a shopping cart for the website.

We will create a feature description in Requirements Management that will describe how the shopping cart should work.
Then we define issues for the specific parts of the shopping cart. This way the developers can start developing it.
Finally, we write the test cases that we should run to make sure the shopping cart is bug free.

Using the Link Issue feature, we can link the Requirements to the Issues and Test Cases.
Under the feature list in the Requirements Management, we can see the issues and Test Cases that are part of each feature.
This way everything is grouped together and we can see the exact status of each part of the project.

If you still don’t have Requirements Management or Test Cases, you should click on the Update Now button below to add these services to your account to make sure your projects are run properly.

Upgrade Now!

Most Common Mistake When Estimating a Project Plan

Hi, I’m Allison, and I want to talk to you about one of the most common mistakes that people make when estimating a project plan.



That mistake is underestimating the time that it will take to complete the tasks due to external pressure to make the project’s schedule shorter than it can actually be.

Let me give you an example: Let’s say that you need to travel from New York to Los Angeles for a business meeting. Your boss asks you how long it will take you to get there, and you reply “6 hours”. The boss says that 6 hours is too long and you should travel from New York to L.A. in 3 hours. You agree, because you want to please your boss, but guess what? After 3 hours of traveling, you end up in Chicago, not L.A. — because it’s impossible to travel from New York to Los Angeles in less than 6 hours!

Believe it or not, this same thing often happens with project scheduling. You set the project schedule proposal and present it to your managers and clients. Then they say that it’s too long and ask you to make it shorter. But the truth is that you can’t make the schedule shorter just to please the clients. Why? Because when you start developing the project, you’ll reach the deadline only half way through the development. And then the clients will get frustrated.

The only way you can truly shorten the project schedule is either by adding more people to the team, or by removing some of the project features. If you and the client are willing and able to do one of these things, then you can realistically plan for a shorter project schedule.

No matter how long or short your project schedule is, you need to be sure to track it carefully. Elementool Scheduling enables you to define project schedules and track the actual progress compared to the plan, which you’ll find is a great help as you try to keep the schedule on target. If you don’t have Elementool Scheduling yet, click on the Sign Up button below now to start your free trial account.