Can Self-Improvement Translate to Project Improvement? Part 1 – Steps to a Better Project

With 2012 still in its infancy, articles still abound about New Year’s resolutions.   Of course, most articles are about how often resolutions fail.  In the most recent issue of Scientific American Mind, the article titled “The Secrets of Self Improvement” is no exception.   The article does give quite a few suggestions about how to successfully pursue self-improvement and as I was reading them I couldn’t help but think about how the suggestions could also help projects.  Projects are improvement initiatives after all, just more complicated.

When a company decides to pursue a change it usually involves a team.  Still, properly applied, what motivates one person can motivate a team.

Four Steps to a Better Project:

1) Realistic Expectations

  • Visualize your success along with the specific obstacles you will face.
  • Avoid situations that trigger habits you want to break.
  • Forgive yourself or your team if there is a slip up; keep moving forward.

2) Find What Motivates Your Team

  • Think about how making this change will help the business become what it aspires to be.
  • Try to come up with fun ways to work toward your goal.
  • Imagine how achieving your aim might strengthen your relationship with your users, team and company leadership.
  • Find a way to measure your progress and track your accomplishments.

3) Take Baby Steps

  • Set short-term, achievable objectives that add up to big change.

4) Formulate Action Plans

  • Prepare your team for specific situations:  “If the code does not meet the needs of the users during testing the functional team will provide me with a detailed description of what the issue is via the issue tracker”
  • Frame your intentions as positive actions.
  • Picture your team carrying out the project plan.

(Adapted from Steps to a Better Self Marina Krakovsky, Scientific American Mind March/April 2012 pg 42)

Project Management Techniques: Agile

Agile is a major buzz word in the project management world right now, especially in the software industry.  My previous post on the Waterfall and Modified Waterfall methods outlined the nature of the most traditional project management models.  Agile is the relative new comer on the scene.

The story goes that one day a group of software developers, dissatisfied with the low success rate of managing projects with the traditional project management methodologies, decided to scrap the old process and design a brand new method all their own.   This collaboration resulted in what is known as the ‘Agile Manifesto’:

Manifesto for Agile Software Development

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

 

Agile is more than a process change, it is a culture change. 

  1. Agile shifts much of the responsibility for determining how things will get done to the team members and away from the project manager and managers.  Managers do not rely on status reports and reams of documentation.  Instead managers rely on a steady stream of delivered, finished products as an indicator of project success.
  2. Much of requirement gathering and communication is done through user stories.  These stories are concise and illustrate in a meaningful way what is to be accomplished to meet the requirement.  This requires more user involvement with the development process than usually occurs in traditional methods.
  3. Their is a lot of flexibility in Agile as the process is intensely iterative (in Scrum an iteration is known as a Sprint).
  4. There is a focus on trust and openness in communication about work done, obstacles and issues.  These are usually communicated during daily stand up meetings with the rest of the team.  They are stand up to keep them short and to the point.
There is a great blog by Kelly Waters, an executive consultant in Australia, called ‘All About Agile‘.  In his post on ‘What is Agile?‘, he lists 10 things that differentiate Agile from the traditional Waterfall methods of project management:

1. Active user involvement is imperative
2. The team must be empowered to make decisions
3. Requirements evolve but the timescale is fixed
4. Capture requirements at a high level; lightweight & visual
5. Develop small, incremental releases and iterate
6. Focus on frequent delivery of products
7. Complete each feature before moving on to the next
8. Apply the 80/20 rule
9. Testing is integrated throughout the project lifecycle – test early and often
10. A collaborative & cooperative approach between all stakeholders is essential

Agile is an umbrella term for more specific methodologies such as DSDM, Scrum and XP (Extreme Programming).   While agile seems magical, it is not a magic bullet.  It does not seem to be a good fit for company cultures that are very traditional and bureaucratic.  It also may not be good for projects that are very well defined and therefore do not need an intensely iterative process.

Project Management Techniques: Modified Waterfall

Free to Go Back

In my last post I wrote about the pure Waterfall Method of project management that moves from one stage of the project to the next without returning to a previous stage.  This method has widely become regarded as problematic because it is too inflexible to handle the inevitable change that will occur as a project progresses.

There is a natural learning curve during any new endeavor and a project is better off if there is some allowance for adjustments based on what is discovered during development process.

The need to make adjustments to an original set of requirements has led project managers to widely a modified Waterfall Method.  This method is also known as the Sashimi Waterfall Model.  This method has the same stages as the original Waterfall Method.  The difference in the model is that the stages have some overlap, meaning that there are many tasks that happen concurrently.  This overlap allow for some back tracking to incorporate changes to requirements based on what is learned during the development stage.

The up side to the flexible nature of this model is that there is a lot more flexibility to correct mistakes and make small changes, leading to less re-work later on in the project.  Another advantage is that there is usually less paper work burdening the members of the project team as the documentation is more in line with the fluid nature of the project.

As with all models, there are some drawbacks as well.  With the introduction of flexibility comes an increase in the complexity of managing each phase.  Since the phases overlap it is harder to close out the phase.  At some point a limit may need to be put on continual fine tuning, allowing further enhancement to come in a later project.  If this limit isn’t put in place the project runs the risk of not staying on schedule.

As with the Waterfall method I’m curious to hear from anyone who has been on a project managed in this way.  What worked well and what didn’t?

Project Management Techniques: Waterfall

In trying to understand the field of project management a good first step is to understand the main theoretical frameworks behind project management methods.  For the next few posts I will be researching these core paradigms and writing about my findings here.

The first method I am lookingwaterfall at is termed the Waterfall Method.   The idea behind the ‘pure’ version of this method is that each stage of the project is completed before moving on to the next without returning to the a previous step in the project.  Each step is considered 100% complete once the project continues on to the next step.

Sounds pretty good right?  Why not start by completely planning the project, following up with creating all the detailed requirements then document all requirements.  Once this is done, the thinking goes, every aspect of the project and its associated tasks will be so well understood that the rest of the project will be a breeze.  All that’s left to do is move the project through the development stage, verify the results and viola! you have a completed project to deliver to your customers.

The benefits to this are supposed to be safety.  The assumption is that if you have everything planned and accounted for up front then you won’t have to deal with pesky issues like big project changes at costly and inconvenient points in the project.  You should be able to come in on time and on budget.

There are many sites where you can find what I think of as “the legend of the waterfall model”.  The idea is that this model came to be adopted by software development from the manufacturing and construction industries. Both these industries have structured physical environment and any after-changes are almost impossible. During the start of software development industry, there were no formal software development methodologies, therefore this model from the manufacturing and construction industries was adapted for software development.

The Waterfall method is generally considered to have some pretty serious downsides and is widely criticized for being inflexible and unrealistic if the goal is to deliver an end product that customers actually want. A project is a complex undertaking and everyone involved has to learn as they go.

David Parnas, in A Rational Design Process: How and Why to Fake It, writes:

“Many of the details only become known to us as we progress in the implementation. Some of the things that we learn invalidate our design and we must backtrack.”

The reality of a need for some level of change management and adaptability in a project has lead to other, more iterative project management methods, such as Modified Waterfall and Agile.

Have you participated on a project that has utilized the pure Waterfall methodology of project management?  If you have let me know how it went and the type of project it was used for.

Project life, project community

As an analyst I have handled small projects and I really enjoy the project management aspects of my  job.   There is enormous gratification to be found in breaking down a complex goal, organizing the resultant tasks into a manageable framework,  and then bringing it all back together to transform potentiality into reality.

As I move toward gaining the knowledge and experience I need to become a full time project manager I become more intrigued with the nature of projects and the managing of them.  It doesn’t take much looking around to realize that projects are everywhere shaping our lives and  our communities.  From the new entrepreneur creating an organic farm or opening a retail store, to renewable energy projects, to the local artist showcasing their work at the latest art show, we live in a dynamic community whose very nature is being shaped by those with the vision and tenacity to actively engage their futures.  Projects are simply a tidy way of compartmentalizing the messy, directed hard work and innovation of regular people creating small directed changes that over time, and with focus, lead to big changes.

This wondrous, endless activity captivates me and my goal with this blog is twofold:

My first goal is to learn about how people create effective change, be it through the current principles of modern project management or otherwise.  As I learn I will discuss what I find here.

My second goal is to speak with the people who, without any project management training at all, manage to create positive change for themselves and the community through their endeavors.   How is it that our fellow Nevadans have accomplished what they have?  What challenges do they still face, or have faced along the way?

I also hope to learn from those who are managing successful projects in our community who happen to have the title of project manager and showcase the positive impact they are making on their businesses, industries, and the local community.

Now as with all new beginnings, I’m looking forward to the journey on which I am embarking.  As with all new endeavors I expect challenges and growth, but it will be well worth it if along the way I can make a positive impact no matter how small.

So what are your thoughts?  Is there a project that you know has just been completed that you’d like to tell me about?  Do you know a project manager that is working on exciting initiatives?  Do you know of a person or group that is actively working to shape our community for the better?  Let me know in the comment section!