PERSPECTIVE: Dispelling some Myths about ITIL

Occasionally, I find people surprised of my interest in ITIL, knowing that the industry I work in is Internet.  With curiosity: “How do you apply ITIL on website and internet!” people ask. In other occasions I found people surprised that I am implementing this gradually without having this as part of a formal and official Implementation program!

That said, I believe there are a lot of myths around ITIL and  I find my self obliged to clarify the ambiguity.

  • ITIL iss a governance framework,  and that’s why it is highly required and valid for industries where governance is usually considered an integral part.

    Completely wrong!. ITIL is a Service Management framework. ITIL is  a set of  good practices build upon the philosophy of thinking of all the effort and activities in the context of providing value to the end user in the form of service.   IT should be  aware that the end result is the value that is delivered and not a working set of IT components! . That said, ITIL can be applied to IT regardless of the industry.
    Continue reading

PERSPECTIVE: Portfolio Management, Resource Allocation and Morale

In ITIL, Portfolio management is  part of the service strategy, which reflects the importance of the process.  Portfolio Management is very important to have a centralized place where all services starting from conceptualization till retirement are listed.

Most importantly, through the service pipeline, we study the services business cases, decide on what services to offer,  and charter the service part of which, is the resources allocation.

Portfolio management provides a holistic vision  of resource allocation to upper Continue reading

PERSPECTIVE: Protect your Strategic Assets

Think about balance

Image via Wikipedia

Why does a client reach you or choose you to provide him with an IT solution or service? Definitely because of the value he believes you’ll be delivering to him. In return of value, he pays you money and, supposedly, enjoys the value you’ve delivered to him.

The value is delivered to the client, by deploying your assets (capabilities and resources) to support and empower the client assets, which in turn, affect the client business outcomes.   Continue reading

PERSPECTIVE: Changing the Vector 2

In an earlier post in 2009, I highlighted the poor quality of IT graduates in Jordan, both in knowledge and practice terms. I supported my case with Global Services Index of A.T.Kearney

In 2008-2009 we went up the ladder very slowly, from rank 14 to 13, which I believe was not enough at that time, taking into consideration that Jordan is one of the leading, if not the only, country to ride the technology off-shoring wave in the region. The major cause that was pulling us down was people skills, we ranked 36th.

I was wrong! Relatively that was an achievement!

Continue reading

PERSPECTIVE: Agile in not a project management methodology

Defined by CollabNetScrum is  a management framework for incremental product development using one or more cross-functional, self organizing team of about seven people each. Scrum provides a structure of roles, meeting, rules and artifacts.

By definition,Agile is a a mind set, as well as, a set of engineering practices for rapid delivery of high-quality software, as well as, a business approach that aligns development of customer needs. Scrum, as well as, other Agile flavors are great  for product development.

However, claiming that Agile – or any of it’s flavors – eliminates the need for a project management methodology, I believe is not precise  . Agile  was not intended to replace project management Continue reading

PERSPECTIVE: Agile and Project Estimations

Customers usually ask: how much? and how soon?

It is inevitable to have answers for those questions. Especially when  bidding for projects, Project Managers usually need to estimate even when  they have no complete requirements document and no signed-off specifications.

Even for internal projects, it is usually hard to get senior management commitment without having at least an order of magnitude estimation for time and cost.

Can Agile answer those questions? Can Scrum?

Continue reading

REVIEW: Using ITIL and Prince2 Together

A  well-organized 6 pages case study published by Best Management Practices illustrating using ITIL and PRINCE2 together in setting up a service desk in an offshore site. Current service desk was reaching capacity and expansion in the current location was not physically possible or cost-effective. The new service desk should follow ITIL procedures.

The case study is very realistic,  easy to understand, relate to and written in a very simple language. The case study illustrates how PRINCE2 supports ITIL and vice versa. Continue reading

PERSPECTIVE: The Best PM Tool!

Since my first days in project management, I realized that existing project management applications are so rigid, at least for software development. Documentation, reports and plans are solely managed and updated by the project managers, reports and status updates are reactive. They are submitted upon request or on timely manner.   Apparently, they perfectly cover planning and scheduling, yet they overlook project members’ interaction.

Projects are very dynamic in nature.  Good project management tools should accommodate a collaborative and interactive eco-system, where project member announce their status, Continue reading

PERSPECTIVE: FDD vs SCRUM

FDD vs SCRUM

FDD vs SCRUM

“At Bayt.com, we had opted to use FDD. While I believe that SCRUM, as all other agile methodologies is excellent in supporting human-oriented software development environment, I continue to believe that it lacks well defined control points (milestones) that are required to track the progress of features implementation. It is clearly focused more on the Project Management side rather than the Software Development side”.

That’s was part of my answer to a question a friend of mine – Husam Saqallah2 asked few months ago. He wanted to know my opinion about SCRUM and how I do compare it to other methodologies, What is the purpose behind SCRUM popularity, while most of the feedback he is getting from PMs Working on big projects was not positive? why more companies are asking for SCRUM experience and who is behind that move, developers or executives?

His question sent me 2 years back in time, where I had to decide on an Agile development methodology. I did an intensive research that drilled down to choose between SCRUM and FDD. I have to say, it was not an easy decision to make, both seemed relevant and practical. Finally FDD won the race for the following reasons:

  1. FDD has well defined control points (milestones) to track the progress of every task. Those control points (Walkthrough, Design, Design Inspection, Coding, Code Inspection and Promote to build) serve the following purposes:
    1. help project manager to track the progress of every task (feature)
    2. provide developers with a very clear flow of each task (feature) implementation and, at the same time, provide interaction client (Walkthrough) and other team members (Design and Code Inspections.
  2. FDD has clearer concentration on quality, though it is not modeled as a role but as a function continuously carried out by different parties involved in FDD; hence I can claim that the possibilities of having a quality product are higher with FDD. Design Inspection is a proactive quality activity to make sure that the feature will be implemented properly while Code Inspection is a reactive activity to verify the implementation. Both help to produce higher quality and avoid rework.SCRUM on the other hand does not highlight details or milestones for every feature implementation
  3. SCRUM overlaps and/or partially covers some Project Manager activities, which as a project manager, is something I do not like. For Project Management I prefer to use a more mature methodology like PRINCE2 – Which I believe is a perfect match of iterative and incremental development methodologies. FDD on the other hand, concentrates more on the implementation/development side at a lower level. Coupling PRINCE2 with FDD worked like a breeze without any confusion or misunderstanding of responsibilities.

FDD was more appropriate for the situation, the context as well as, my personality! That does not necessarily mean that FDD is absolutely better, SCUM cannot produce quality products nor always fails. Though I have my conservations and concerns about SCRUM, I found the feedback my friend collected from Project Managers is biased and we cannot blame SCRUM for this.

I believe any software development methodology will fail at that level, as they are not supposed to be responsible of this – though I blame SCRUM or any agile software development methodology guys for claiming that their methodology can handle big projects by their own. Handling big projects requires advanced project management techniques and approaches. Such projects should be undertaken as a program, where project is split into multiple modules/sub modules that can be managed as separate projects. Separate projects can be executed with SCRUM – or any other methodology -, while coordination between projects is done on program level.

Finally, I believe we should not overlook the importance of the human factor; a methodology might not fail because it is not mature, practical or verified, but because you haven’t secured the buy-in of all participants. Getting stakeholders acceptance to the cultural change you are proposing is one of the most challenging – if not the most– factor is the success of any process or methodology.

Who is behind SCRUM? Honestly, I am not sure, but what I am sure of is that it is there for a reason, same as FDD.


1 FDD stands for Feature Driven Development. One of the Agile software development methodology.
2Husam Saqallah is a friend and the CEO of astroClipz, Inc.

 

At Bayt.com, we had opted to use FDD. While I believe that SCRUM, as all other agile methodologies is excellent in supporting human-oriented software development environment, I continue to believe that it lacks well defined control points (milestones) that are required to track the progress of features implementation. It is clearly focused more on the Project Management side rather than the Software Development side