projectified-old

Glen is on a Roll!

Glen is in a groove riffing on Target Process’s post.

It may be the Target Process just needs to get a better marketing plan, cause from where I sit MSFT Project and other "big name" project management tools do everything they claim they do. They'll need some other way to differentiate their product.

I think this is the key point. I looked at their tool and I would not put them in the same category. Project is a scheduling tool and the Target Process tool seems to be a work management\team collaboration tool ala Basecamp. I don’t think these two tools are really competing. I dont see the average customer of their tool having to weigh their product versus Project. There is almost no feature overlap other than that they both contain things that could be called “Tasks” and those tasks are assigned to human beings.

All I can think of as the rationale for this is that it is fun to bash MS and agile dev people love to bash non-agile methods. This is a no brainer: a two bash for the price of one deal! They got to bash MS and non-agile methods at the same time! :-)

 

News of Project's Death with Regard to Software Projects Has Been Exaggerated. Again!

 So the guys over at Target Process just informed the world that Project is based on the waterfall process and is therefore unsuitable for use in managing a software project! LOL Wow that is news to me and the thousands of others that have used to manage iterative software development projects! :-)

I posted a comment on their post that talked about my disagreement and have had this response in draft form ever since and had forgotten about it until Glen posted on the subject. It was not until I read Glen’s post that I realized that Target Process markets a product that competes with Project! This certainly casts the post in a different light. When I first read it  I did so with the thought in mind that the writer was just not understanding how scheduling software really works or what the basis is for building and indeed using such software. But knowing that the poster works for a company that competes with Project it now just smacks of an intentional distortion of the facts with the end goal of boosting sales of their product. While this certainly may NOT be the case (I really want to believe that this was not the thrust of their post) it certainly starts to look that way.

Microsoft Project is not based on “Waterfall”
It just isn’t. Neither are the scheduling engine components of Primavera, Niku (sorry I meant CA), Artemis, Planview or any other major scheduling application that I have seen. You can MAKE them do waterfall. You can make any application do waterfall. I can make Basecamp do waterfall and you could likely make Target Process’s tool do waterfall too no mater how centered it’s design is on Agile. Hell, I can make 3x5 cards like the ones used in XP\Scrum do waterfall!! Waterfall is a process for planning a project. It is not tool specific. It is project environment specific. Waterfall can work as a method for scheduling software projects. Not many in my opinion but they are out there. The method you use to plan your work (be it a software project or the creation of marketing materials or the building of a dam) should be context sensitive. If you have the requirements up front and they will not likely change through the course of the project then waterfall might be the thing. In a case like this an iterative approach might add loops that are a waste of time given the locked down nature of the requirements. If you are building something there the requirements are fuzzy and likely to change over time then the obvious choice is a method that is iterative at it’s core (whichever method that might be for your case.)

As I mentioned in my comment on the original post I agree that the Help file that comes with Project should address other planning processes. In fact in my Outlook outbox (I’m on a plane right now without Internet access) there is currently an email to several people on the Project development team suggesting just that. However, the mere fact that the Help only mentions waterfall type methods does not mean it is based on waterfall nor does it mean that you cannot use Project to do iterative projects. To suggest otherwise is like saying you cannot toast a bagel in your new toaster because the instructions only mention bread and English muffins. :-)

Project IS “Connected”
These comments really just seem like marketing spin to me and have been covered in my comments on the original post and in Glen’s post. Suffice to say that Project Server addresses these comments have little to do with the suitability of Project as a scheduling engine for software projects. A deck of 3x5 cards used to organize SCRUM or XP tasks are not ‘connected’ either since only one person can ‘hold’ them at a time so give me a break. :-)

 

Iterative Design\Build Loops in the Configuration of Project Server: First Pass and Initial Thoughts

I have always been a fan (and in fact a major proponent) of the idea of iteration in the long term deployment and roll out of Project Server across an organization. Myself and Russ Young of QuantumPM were one of the first ones to talk about this in the Enterprise Project Management Deployment Guide way back during the Project Server 2002 days. Our work in this area was based on ideas that were widely held not only in the Project Server consulting world but in almost all enterprise software organizations. These iterations were fairly large scale ones dealing with the staged, incremental roll out of Project Server to the many organizations within a larger organization as opposed to the massive one-time dropping of Project Server on the entire company. This approach started with a small but representative (as much as possible) group or small organization and then using the lessons learned from this group the system would be adjusted (new fields added, new views, server architecture adjusted, etc) and then another group would be added. This process would repeat until the entire organization was using the tool. Each iteration added not only new people but also new or fixed functionality in the form of views, security, process, etc. This method is now used by virtually every consulting company doing Project Server deployments.

The kind of iteration I’m talking about here happen on a much, much smaller scale and deal with the actual design and production of the configuration of the Project Server system for a given organization. Instead of dealing with the successive roll out to new organizations I'm now talking about the iterative design\build loops around adding new fields, views, security configurations within any one of those larger iterations.

Understanding of the Environment and the Problem(s) to be solved
This includes the collection of what the users want the system to do for them in addition to the observation of the system at work so that you as the consultant can help make suggestions.

Configuration\Build
From the knowledge gained so far the system is configured to the best of your ability. Fields, views, security, etc.

Simulations
most organizational uses of tools like Project Server revolve around the capture and editing of project data and then in the use of that data to make specific business decisions that effect the ability of the organization or project team to function with regard to projects. I look at kernel, the very core of Project Server’s use in an organization as the viewing of data via views or reports by decision makers. Everything else that project Server does supports this in some way or another. With this driving principle in mind the check or test of the configuration\build ‘stage’ is a simulation where decision makers use the tool as it is currently configured to simulate the decision making processes they must go through to manage their work\projects\portfolios\etc. These simulations have the decision makers using the tool in a conference room with the design team and other decision makers up on a projector. Talking through the decisions they need to make and what data they would need to see to make them. How it would need to be displayed, grouped, sorted, how it should be secured, who can see it, who can’t see it, etc.All effort toward a better understanding of how the tool will be used and what decisions it will be used to support.

Revisiting the build stage…
At this point we jump into a loop of Configuration\Build and Simulation loops that successively improve the suitability of the Project Server configuration to the needs of the decision makers that will be using it to run the business\projects\work.  If this means new views or fields then so be it. If it means configuring and rolling out the use of timesheets to those doing the work or the development of custom OLAP cube building routines to provide company specific data in Portfolio Analyzer views then that is fine too.The point is that the design\configuration happens based on simulated use of the product as it is configured currently.

___

This process can take place either prior to the system ‘going live’ or as part of the addition of new users to the system. Also, a variation on this process happens on an ongoing basis while the system is being used by the organization. As people touch the system and use it as part of their project management\portfolio management processes their new experiences and new expectations become, often, new requirements for the system. The administrator of the Project Server system should constantly collect suggestions and new requirements and evaluate them with the team for inclusion in the system. This constant updating of the product’s configuration ensures that it keeps up with the most current processes in use within the organization.

___

Obviously this is not rocket science and I'm not claiming to have ‘invented’ it by any means. I’m sure that many others are using similar processes for their Project Server (or other PM software) roll outs. I should also mention that this process is only suitable where the organization is able to devote several weeks (at least 3 or 4) to this initial design process. Often organizations that are rolling out Project Server have only a very short time to do their initial design and configuration. In cases like this the process laid out here may require too much time. But it should be said that while this process requires more time than many methodologies it is much more likely to produce a usable system. Shorter term processes get you up and running very quickly but at the cost of fully understanding the processes and needs of the organization.

This is just an initial layout of rough thoughts on this process. It is by no means final.

 

OK, Maybe Not Worst but Now Certainly the Most Incomplete...

The other day I posted about a Churchill quote and Glenn has some interesting insight to it’s value.

Glen mentions the Apollo space program as being built upon a series of failures to eventually produce a great series of successes. I agree with Glen in his comments that and quotes about learning from failures. That is certainly a key part of any project, no, any LIFE.

However…the quote mentions nothing of learning from mistakes and failures. It instead defines success itself as the enthusiastic movement from failure to failure. I think we can all agree that the movement from failure to failure that Churchill describes is not only NOT a definition of success but it is in fact, without a major (MAJOR!) success at the end, a pink slip waiting to happen.

So that said, it seems that to make the quote what Glen is suggesting would mean adding something like: “…leading up to a success based on lessons learned from the failures provided of course that the positive value of the success outweighs the negative value of the string of failures.”

New Project Blog

Larry Duff from Microsoft has a blog that is mostly about developing in and around Project and Project Server. It is a MUST read for those doing Project Server development, particularly when the next version hits. The insights he will have since he has been messing with the new PSI stuff will be HUGE!

The Project Conference

The conference, as usual, was very well done. The only substantial complaint I heard was that the most popular sessions filled up too soon and some were not repeated. I can understand this but for sure it is hard to know which ones will be in the highest demand. You can have a good idea going in but there are always surprises once the sessions get going.

Treb and Dieter have already gone into the new features so I will not repeat their fine work.

I am excited most about these though:

• Segmented databases (Working, Draft, Archive and REPORTING)
  This is going to make life very nice for those working with custom reports and also solve some issues around archiving
• Project as a WSS application
  Having Project Server as an integrated part of the WSS ‘framework’ will make building customisations much easier and addresses some of the UI consistency issues that were around from before
• Server-side Scheduling Engine
  VERY cool stuff. The ability for a PM to accept timesheet\status updates and have those updates put right into the schedule without the PM having to be at a machine with Project Pro installed! It will also allow for custom applications to add data and have the project recalculated based on those changes without having to automate Project Pro.
• Deliverables
  This is the feature where a task from a project can be ‘published’ and then subscribed to from other projects reducing the need for the ‘old’ cross project dependency links between tasks. A PM ‘publishes’ a task and then any other PM can ‘subscribe’ to that and make it the predecessor to one of his own tasks in his project. Basically it is creating a cross project link without having to have both projects open at the same time to do it.

How UMT gets integrated into the product is another obvious area of excitement. I am very anxious to see how it will play out.

More later…

Obviously I Got Too Busy...Sorry

So the conference has been over for several days and I have not posted anything on it yet. I was slammed while I was there reconnecting with those I had lost touch with in the last year and I have been slammed with customer work since then.

In the next week or so I will try to put up some info I learned.

For now I will say that the next version of Project\Project Server will be VERY cool and will make for exciting times for everyone.

Oh by the way...I Work for Microsoft Now...

I guess I should mention that I now work for Microsoft Consulting Services now. They are staffing up a group to add the ability to assist partners and large customers with Project Server deployments and the PM and Portfolio Management consulting that surrounds these deployments.

So anyway those that thought I was too Pro-Microsoft will think it for sure now! :-)

Blogging the Project Conference

Starting tomorrow the Project Conference in Seattle is on and I (along with others) will be blogging the high points. I will try to distill what I’m seeing and hearing into something like readable nuggets for those not able to attend.