You are here: Home Blogs
Project Management Blog
Blogs

Blogs (1354)

Rate this item
(0 votes)
this content is from the TenStep weekly "tips" email dated 2017.05.10

Agile in Practice – Four Reasons to "Build for Today"

One of the philosophies of Agile projects is to “build for today.” In other words, you should design, build and test only what is necessary to meet the needs of the user stories that are selected in the current iteration.

In some respects this goes against the intuition of many team members that feel it is more efficient in the long-term if they take into account potential future requirements. The thought is that you should build to support this future functionality “while you are there” and then later when the requirement is actually selected you can finalize the work with much less effort.

In the Agile model this is generally seen as a false tradeoff for four reasons.

  1. First, the time it takes to design, build and test to support future features will mean that you cannot get as much done in the current cycle. You are supporting fewer current, concrete, high-priority requirements in exchange for vague, distant potential future requirements. This is not seen as a good trade-off.
  2. Second, it is possible that this extra, future functionality will never be needed or requested. The customer may have requested this future functionality in a traditional project, but in an Agile project, the difference between “wants” and “needs” is much more focused. Who knows if the extra functionality will make it into a future iteration? The world is full of systems functionality that is written into programs but never utilized.
  3. Third, it is very possible that you may not implement the future requirement correctly anyway. The product owner will not discuss it or test for this future condition. Even if a future requirement seems simple and fully understood, it is possible for misunderstandings and errors to occur. Then you are out-of-synch trying to test and debug problems that should not even be a part of this iteration. Each cycle will also have its own challenges. You don’t need to compound things by introducing problems that are not a part of this release.
  4. Fourth, if the extra functionality is needed in the future, it will have its turn in a future cycle. When the functionality is chosen, the work will be constructed and tested. In an Agile project, you will likely visit the same sections of the solution multiple times. You don’t have to worry about building extra functionality “while you are there” because it is very likely you will “be there” many more times before the project is completed.
This philosophy should be applied for process functionality, performance, security, etc. The “build for today” approach is also an example of “minimally sufficient,” which is another Agile philosophy. You want to make sure that you do everything required to support the customer needs, but no more. 



At TenStep we are dedicated to helping organizations achieve their goals and strategies through the successful execution of critical business projects. We provide training, consulting and products for organizations to help them set up an environment where projects are successful. This includes help with strategic planning, portfolio management, program / project management, Project Management Offices (PMOs) and project lifecycles. For more information, visit www.TenStep.com or contact us at admin@TenStep.com
Rate this item
(0 votes)

399Click Here to Listen to the Interview: http://bit.ly/PMPodcast399
Read More: http://bit.ly/PMPodcast_399

The one thing I really like about project management is how unpredictable my days can sometimes be. I come to the office in the morning with a clear plan of what we are going to do today, and then something happens.

Maybe something breaks, a critical resource is unexpectedly not available today, or -- even more normal -- the customer wants a change and he wants it now. I love this challenge, because as a project manager I now have to re-evaluate the situation and change my plans accordingly. That is situational project management.

However, there's more to situational project management than just responding with a knee-jerk reaction. These times demand situational awareness, skill and finesse from us project managers.

And so I’m very happy to welcome Oliver Lehmann (www.oliverlehmann.com -- www.linkedin.com/in/oliverlehmann/) who literally wrote the book on this topic. The book is called Situational Project Management the dynamics of success and failure.

Rate this item
(0 votes)
his content is from the TenStep weekly "tips" email dated 2017.27.09

There Are Three Main Project Organization Types.
Which Are You?


The way that the project team is organized is directly related to the way the entire organization is structured. There are three major organization structures to manage work and people.

Functionally Based

In a functional organization, a project team is generally staffed with people from the same department. For instance, if the project is related to the finance function, the project resources come from the Finance Division.

Another way a project is staffed in a functional organization is by executing portions of a project in separate functional organizations. For example, let’s say that a large project needed resources from the Finance, Purchasing, IT and Manufacturing departments. In a functional organization, the project would be broken down by organizational unit and each unit would do its own part relatively independently. At the end, all of the independent solutions would be integrated into one final solution.  

The biggest advantage of functionally-based projects is that there is usually clear authority, since the project managers tend to also be the functional managers. A major disadvantage of the functional organization is that your functional area may not have all of the specialists needed to work on a project. A Finance project with an IT component, for instance, may have difficulty acquiring specialty IT resources.

Project Based

When projects are large enough, it's possible to form functional departments around the project team. This is especially practical when a large program has hundreds or thousands of people assigned over a long period of time. Advantages include clear authority, since the project manager is also the functional manager, and a clear focus, since everyone on the team has only the project for their primary responsibility.

One disadvantage is duplication of resources, since scarce resources must be duplicated on different projects. For instance, a large project may have its own Human Resources staff, which could duplicate a central Human Resources Department. There can also be concerns about how to reallocate people and resources when projects are completed. In a functional organization, the people still have jobs within the functional department. In a project-based organization it is not so clear where everyone is reassigned when the project is completed.

Matrix Based

Matrix organizations allow functional departments to focus on their specific business competencies and allow projects to be staffed with specialists from multiple functional organizations. For instance, a Legal resource might report to the Legal Department, but be assigned to a project in another department that needs legal expertise.

The main advantage of the matrix organization is the efficient allocation of all resources, especially scarce specialty skills that cannot be fully utilized by only one project. The matrix-based organization is also the most flexible when dealing with changing business needs and priorities.

The main disadvantage is that the reporting relationships are complex since many people have multiple work managers - both a functional manager and one or more project managers. Staff members need strong time management skills to ensure that they fulfill the work expectations of multiple managers.

Summary

The matrix-based organization is the most common. Can you tell which model your organization uses?  

At TenStep we are dedicated to helping organizations achieve their goals and strategies through the successful execution of critical business projects. We provide training, consulting and products for organizations to help them set up an environment where projects are successful. This includes help with strategic planning, portfolio management, program / project management, Project Management Offices (PMOs) and project lifecycles. For more information, visit www.TenStep.com or contact us at admin@TenStep.com
Rate this item
(0 votes)
This content is from the TenStep weekly "tips" email dated 2017.20.09

How Do You Handle Projects With
Predetermined End-dates (Timeboxing)?


In a perfect world, your project schedule and completion dates would be derived based on the amount of work to be done and the number of resources available. As you know, that is not always the case. Sometimes when the project is assigned, it already has a targeted end date. For instance, the end-date may be determined by a government regulation, a scheduled event or to coincide with another company initiative. This situation is referred to as a "timebox", meaning you have a fixed amount of time to get the work done and the end-date is “boxed” in.

There is nothing wrong with having a fixed end-date. It can give everyone on the team a sense of urgency and focus. There may be a problem, however, if the project manager and team do not think they can get the work done by the deadline. In that case, the project manager needs to raise this as a risk. Potential risk plan actions include:

  • Assigning more resources to the project. Too many resources may have diminished value but this is usually the first place to start.
  • Having the team work overtime, with the understanding that overtime itself has a diminishing return, and that long-term overtime can actually have a negative effect.
  • Working with the stakeholders to scale back the scope. This may include removing entire deliverables or functionality from required deliverables.
  • Determining whether some required deliverables and features can be delivered later than the due date. For example, a 90% solution may be viable at the due date, with the additional work completed soon after.
Important -  Estimate the Amount of Schedule Risk

Even if your manager or sponsor has given you a fixed end-date, it is important to carefully build the schedule first as if you did not have the fixed end-date. If you do this first, it will give you a sense for how realistic it is to hit the fixed date. For example, let’s say you have a project that has to be completed in nine months. If you first create a “normal” schedule that shows the project will be complete in 9 ½ months, it would not be too much of a stretch to think you could complete the work in nine months. However, if you create a “normal” schedule and it shows the end date at 13 months, you will understand the difficulty and the risk associated with trying to get all of the work completed in the nine-month timebox. This does not mean that you will not have the nine month deadline. However, it gives you more information to have a fact-based discussion on the project risks and options that are available to you.  

At TenStep we are dedicated to helping organizations achieve their goals and strategies through the successful execution of critical business projects. We provide training, consulting and products for organizations to help them set up an environment where projects are successful. This includes help with strategic planning, portfolio management, program / project management, Project Management Offices (PMOs) and project lifecycles. For more information, visit www.TenStep.com or contact us at admin@TenStep.com
Rate this item
(0 votes)


398Click Here to Listen to the Interview: http://bit.ly/PMPodcast398
Read More: http://bit.ly/PMPodcast_398

Every project that you and I have ever and will ever manage depends on people’s skills.

The sponsor relies on you as the project manager to successfully lead the team, you rely on the team to have what it takes to create all the deliverables at the required quality, and the end user -- the recipient of what you and the team deliver -- must have the skills to use the product you finally give them.

But what if the skills don’t match up to the tasks at hand? What if a team member is lacking a skill? What if the technology is so new and different that your users will have a hard time with it? The answer is of course coaching, mentoring and training.

And there is no one better than Susanne Madsen (www.susannemadsen.com -- www.linkedin.com/in/susanne-madsen-1134312) who coaches and mentors project managers into project leaders to come on the program and help us understand these three similar yet different activities.

News and Promotions

Keep up to date with the latest happenings by signing up for our newsletter. Subscribe below.

Twitter Update

Who's Online

We have 1044 guests and no members online

Got something to say?