Showing posts with label requirements. Show all posts
Showing posts with label requirements. Show all posts

Monday, July 18, 2011

So Little Time, So Much To Do!

Insufficient Time to Complete the Project is ranked third as a cause of project failure globally according to the 2010 Global Survey, Top 10 Obstacles to Project Success.  This article is meant as a precursor to more in depth information regarding the; causes, impacts, early detection, and mitigation of this complex and often misdiagnosed project obstacle. To read the full article, go to http://www.mutoperformancecorp.com/2010SurveyResults.htm

Sunday, October 5, 2008

On Project Completion

“What obstacles do project managers face to successful completion of an Information Technology project?”

Project Management and IT Professional

Successful completion for me does not mean a project was delivered on time or on budget it means that the projects goals were accomplished. A successful project is one that produced deliverables which met or exceeded the stated business goals.

For me the biggest obstacle to a successful project is the misstatement, understatement or misunderstanding of goals. I have worked at many companies and completed many projects and most of the stated business goals dont always seem to make it to the Project Manager. Often times the goal presented to the PM is "implement this" instead of achieve goals 1,2,3 through the implementation "of this" which goes to explain what the business is really trying to achieve. I am often forced to re-interview the stakeholders to be able to produce a statement of goals that is shared with and periodically reviewed with the project team.

Other common obstacles:

Scope creep – this is fairly common and is caused primarily by a poor understanding of the goals which causes scope statements to be incomplete. Typically discovery of this is not made until much later and almost always results in more work. The addition of business goals on the other hand is also creep but schedules can and should be renegotiated to accommodate.

Resource allocations – Ask any PM is she or he has ever had too many technical resources on a project. Chances are no. Often times other factors are used to set target delivery dates when the actual primary driver should be the availability of resources.

Schedules – There is never enough time or resources to meet project schedules and this often results in poor work. Quality and innovation always suffer the most from this. If there is barely enough time to check in the often buggy code, how innovative do you think it will be.
There are many other obstacles of course but do feel free to contact me to discuss.

MüTō Observation:

For example, the basic inability of a project manager to communicate clearly can lead to 'scope-creep', and a misunderstanding of the requirements, or worse yet, the loss of understanding of what the 'danged business objective is!'

Its tantamount that a Project Manager understand the business objective; At least in its native form. It may be a big leap between the understanding, and their particular project, but at least they would know WHY the project is important, and then they can communicate that importance to the rest of the team. Without that understanding the entire team would be working in a vacuum, and could never be properly motivated.

Tuesday, June 3, 2008

On Requirements

“What obstacles do project managers face to successful completion of an Information Technology project?”

System Administrator; Financial Services firm

“REQUIREMENTS, well stated, and upfront is the key to successful completion of any project; not just IT projects. Creating requirements on the fly while in the midst of a project indicates poor planning, creates havoc with all team members and produces false positives as to when the project can or will be completed. It is important to recognize that IT projects are inherently complex and require a considerable amount of planning and forethought before exercising. But in order to plan and account for budgets, time and energy, one must fully grasp and tackle the REQUIREMENTS! Be wary, do not make them up as the project flows...”

MüTō Observation:

Requirements are tantamount. So, the PM's ability to LISTEN, and make certain that the business is 'winded', and that IT has no further exploratory questions is tantamount as well, eh?


One way for Requirements to be guaranteed is for PM's to accept the responsibility of making certain all parties are in agreement on 'what the project requires' before moving onto building it.

Funding changes happen, but they become easier when they are not surprises/scope changes. On that...the business is the business, and they reserve the right to change their minds...but SOMEONE has to hold them accountable for the issues that will raise on a project. Business folks appreciate it, if handled appropriately.