jump to navigation

Innovation Vs Cost-Containment July 1, 2009

Posted by newyorkscot in Articles, Client Engagement Mgt.
Tags: ,
add a comment

Luke met with the good folks at Advanced Trading at SIFMA the other week, the result of which was this article “SIFMA: Cost Cutting, A Double-Edged Sword?” that outlined his observation on the maturity of the purchasing decisions investment banks make (or don’t make!) in hiring consultants: 

Level 1: Lowest dollar cost – is it really the cheapest option if it takes twice as long ?

Level 2: Total Cost of Project – factor time to completion, debugging, compliance, etc

Level 3: Risk-adjusted cost perspective – probability of success for the investment

Level 4: Innovation – the need to bring new ideas to the table

Needless to say, there is indeed a tight correlation between these levels and the timeliness/quality of the final product….

How to Be a Good IT Customer August 7, 2008

Posted by newyorkscot in Agile, Articles, Client Engagement Mgt, Management.
add a comment

Joe Morrison and I have another article published in eBizQ that discusses on how clients and customers can help developers do a better job in delivering better functionality in a quicker timeframe. See also our previous article published in Computer Weekly.

How To Be A Good Customer July 8, 2008

Posted by newyorkscot in Agile, Articles, Client Engagement Mgt, Marketing.
3 comments

Joe Morrison and I just had an article published in Computer Weekly that summarizes how business customers can play a role in IT teams delivering better software more frequently and reliably. Read the article at Lab49 here, or online here.

Mingle April 15, 2008

Posted by newyorkscot in Agile, Client Engagement Mgt.
Tags: , ,
add a comment

One of our guys just downloaded the latest version of Mingle, the project collaboration software from Thoughtworks. On initial inspection it seems to provide a nice visual interface to specify and layout features, tasks, etc for different views of the product and iteration backlogs (including a Card Tree for laying out cards in what looks like an org chart). It also supports some pretty slick (and configurable) burndown charting for whatever data you are interested in, and has a wiki for documentation. It seems to be striking a decent balance between developer collaboration and management reporting.

One feature in particular that looks really useful is an interactive online version of a card wall.  Not only is this customizable, but it can total up work effort per swimlane (which is what used to pain me when we used to use real cards & pinboards). Pretty cool stuff.

Will be interesting to see what others think of this compared to XPlanner, etc, and whether people will pay for it (it costs for projects with more than 5 people). What do people think of this compared to other “paid-for” offerings from vendors such as VersionOne and Rally ? On initial glance, it looks very functional and seems to be very flexible.

Quick Burndown Chart Update March 7, 2008

Posted by newyorkscot in Agile, Client Engagement Mgt, Management.
add a comment

In a previous posting, I mentioned that we had been using Google spreadsheets to track iteration backlogs and to create burndown charts for our agile projects. At the same time, we had been using our wiki for capturing all project-related risks, issues, dependencies, decisions, designs and documentation. Well, the good folks at Google now allow chart publishing (to a URL) such that we can now keep our burndowns “live” in the project wiki for clients to see. All I need to do now is find the right confluence plug-in to allow me to keep a live product backlog in the wiki (Google also allows spreadsheets and cell/named regions  to be published to URLs in various formats).

Lab49 Client & Marketing Update.. December 12, 2007

Posted by newyorkscot in Client Engagement Mgt, Complex Event Processing, HPC, Marketing, SOA / Virtualization, Visualization / UX.
add a comment

The last few months and weeks have been a bit mad with a host of new client projects coming online, and a tidal wave of marketing activities.

On the project front, and despite some dodgy market conditions, we have been continuing to see (and have started) some interesting projects around automated trading: from market simulation environments to real-time pricing to risk management systems. We have also seen more projects on the buy-side where the level of innovation and adoption of the latest technologies is still impressive. In advanced visualization (specifically, WPF/Silverlight), we are starting to see interest across various trading businesses which is very promising going forward. We also continue to be involved in quite a few projects involving grid computing, distributed cache, etc.

On the marketing front, we have been busy publishing new articles, contributed to a number of features in various industry publications and are currently in the process of writing some thought leadership pieces for technology and finance publications. We have also been doing some great sales & marketing activities with some of our technology partners around, including working on some new client opportunities and developing some demos leveraging WPF and CEP platforms. (We will also be starting to talk a bit more openly about our various partnerships)

What’s great about the recent flurry of project and marketing activity has been the balance across high performance computing (grid, cache, etc), Java (J2EE, Spring, opensource), Microsoft (WPF, Silverlight) and other technologies (messaging, market data, visualization, etc), which really helps to show Lab49‘s depth and breadth across the technology space. Some highlights from the last few months include:

Lots more news, articles, features, partner updates, etc in the pipeline that I will post as they happen..

BEA Event Server Fixed Income Demo September 19, 2007

Posted by newyorkscot in Audio & Video, Client Engagement Mgt, Complex Event Processing, Marketing.
5 comments

Lab49 has been working with BEA on their new Weblogic Event Server (WLEVS) product in the complex event processing space. As part of this effort, we have been building a demo of how one could automatically reprice a portfolio of fixed income instruments against streaming market data. In addition to WLEVS, we used Quantlib‘s C++ libraries and Lab49’s own market data simulator, with the front end built in WPF.

A couple of us from Lab49 attended the BEA World Conference in San Francisco last week and I presented the demo as part of the “Introduction to Event Server” session.

Click on the image below to view a screencast of the demo .. (this is a .wmv version for the moment..)

We were able to run the demo pricing 400 bonds/sec, with 4.6ms latency, on an Intel Quad processor – the folks at Shuttle helped us with their latest snazzy new XPC box. We also developed a cool WPF visualization of the Event Processing Network where we can automatically generate XAML from the underlying EPN configuration which we then data-bind to the event server’s performance monitoring meta-data.

I will put the demo and more information on the Lab49 website, and hopefully we will get it onto BEA’s Dev2Dev portal soon…

Bad Functional Specifications July 12, 2007

Posted by newyorkscot in Client Engagement Mgt.
6 comments

How many times do you get a functional requirements document that has been very carefully prepared for you in advance, only to realize within nanoseconds what a the can of worms you have just split open ? And that this is going to be a very painful exercise in figuring out what the original intention of the system was supposed to be ?

In this day and age of software development, you do wonder how come people can write such bad specifications. There are so many ways of articulating functional requirements, many of which are very simple such as use cases or stories.

It seems to me that the overarching problems with specifications (other than them going out of date as soon as they are completed) are communication and context (or lack thereof). Often the folks doing the specifying suffer from at least one of the following; a) they do not know what other people know and hence how much or little background to give, b) they do not know what the consumer of the specification is looking for (are they building an application, validating a methodology, testing use cases, etc ?), c) they do not know where to draw the line in terms of what is current scope, versus future needs.

After having to digest some of these gems recently, I felt the need to get some “observations” off my chest.  If you need to write a functional specification such that your software development team gets off to a very slow and confused start, please ensure that:

  • Irrespective of content quality, it is large enough to hold a barn door open.
  • It makes gross assumptions – especially where core functionality absolutely needs data that  may not exist.
  • It contradicts itself all over the place.
  • It has plenty of ambiguities and maximizes the overloading of the meaning of words. (Note: if you are going to do this make sure to randomize the use of these overloaded words)
  • It combines irrelevant background and theory with low-level implementation details.
  • If it exists, make sure that the document is based on a previous edition of the system you are trying to build, and provides no foresight into future requirements.
  • It specifies in excrutiating detail every single data field you might need, including temporary data fields that were used to badly program the previous edition of the system.
  • It actually include snippets of badly-conceived legacy code to illustrate future business requirements.
  • It includes highly detailed and comprehensive requirements for features that are not in scope.
  • It copies and pastes mathematical theory from well known resources (such as wikipedia, text books), and deliberately change the explanation of what’s going on. For extra points, omit important transitional steps in the theory.
  • It embeds any concept of workflow deep into the document, and that each workflow process is fragmented and scattered throughout like a jigsaw puzzle.
  • And finally, it never once mentions the functionality required by the actual end-user

More sarcastic contributions appreciated…

Delivery Of An ABS Pricing Platform For Interactive Data April 19, 2007

Posted by newyorkscot in Agile, Client Engagement Mgt.
add a comment

We have been working since last summer on a brand new shiny pricing platform for European Asset-Backed Securities for Interactive Data Corporation (formerly Financial Times Interactive Data). IDC just made the a press release about it –read it here and on the Lab49 website.

The cool thing about this project is that is was built from scratch, was run as a formal Scrum project, was developed offsite in the Lab, is part of the client’s new strategic architecture, the client-side stakeholders were a joy to work with, and our team rocked !!

I will write more details on the project later, and will hopefully get a brief case study up on the Lab49 website soon.

Burndown Charts, Wikis & Spreadsheets July 21, 2006

Posted by newyorkscot in Agile, Client Engagement Mgt.
6 comments

We have been executing a new client project using a set of iterative development tools & techniques, with Scrum as the overarching management process delivering on 30-day deliverable cycles. Accordingly, the burndown chart has been updated daily based on the work effort remaining for each task the team has defined in its iteration backlog.

In general, when we show and examine burndown charts with clients for the first time, there is definitely a “wow” factor, as this simple visual display contains almost all of the information they need to readily understand the project status. When we then present this information to clients via a Lab49 client wiki page (we use Confluence ), which contains a continuously updated set of issues & impediments, it tells a very detailed account of the project and gives the clients more transparency than they have seen before.

For this particular iteration, we thought we would try using Google spreadsheets to manage the tasks & work remaining — this has been decent tool to allow a single-point for the entire team to update progress and Google’s (AJAX?) front end offers a decent chatroom function for those viewing the spreadsheet. Like a few other collaborative spreadsheet services I have tried (such as Num Sum) the lack of charting is a pain as I have to export the data to Excel but all in all the benefits of the collaborative data management outweighs this. I have tried other agile tools such as XPlanner, but often pefer the simplicity and flexibility of a spreadsheet.

Going back to the burndown …. most traditional project management techniques do not provide an intuitive and simple way for the team (and client) to review how the project is progressing on a daily basis, nor do they provide such a granular level of refactoring of estimates of work remaining. 

One of the interesting things in looking at the burndown is the easy nature by which the team can see how far ahead/behind schedule (relative to a “perfect burndown”) the iteration is at any point in time. (This key feature is not readily available in traditional techniques). However, the daily inspection of both task-level work effort and iteration progress provides a higher frequency of datapoints, which in turn drives a really granular view of trend shifts where small deltas in the overall trend might actually highlight underlying issues and risks that may have otherwise have gone unnoticed. In other words, the trend is can be more insightful as the data itself.

What I would really like to have is a truly collaborative online spreadsheeting function that contains more powerful formatting, analytical and graphing functionality, that I can then reference in-line from my client wiki page to provide truly dynamic updates. I see (one example here) that Dan Bricklin ( the co-inventor of the original spreadsheet – VisiCalc) has developed WikiCalc has some ideas in motion, including working closely with Socialtext. Other suggestions welcome …

New Opportunity June 17, 2006

Posted by newyorkscot in Client Engagement Mgt.
2 comments

After a number of interesting weeks and discussions,  I have found the next chapter of my career: Director, Client Engagements and Marketing at Lab49.

Since my previous posting, I had been looking into a number of potential job/career opportunities including some things in technology marketing, including agency side careers, and although this shares some of the same attributes as working for a consulting firm, I don’t think I can leave the IT/delivery side just yet.

I had also been speaking to some people who were just getting into new ventures, very much in the start-up mode. Although this is exciting and many entrepenuers have some great ideas (and even better and very compelling sales pitches), I have actually done this before. But it is very difficult to get a sense of reality when there is no solid pipeline or backing.

When I spoke to Luke and Dan at Lab49, I got a great sense of the energy, culture, passion, innovation and intellect that exists at the company. Not only have they been doing some really solid (and in some cases cool) delivery in Capital Markets (such as trading, risk mgt, pricing systems, etc), but they now have some serious backing: Corpus has aquired Lab49, with Lab49 becoming the Financial Services division of Corpus. This means that they are investing in the talent, putting in place a scalable infrastructure and are serious about their profile in the industry (they have hired Write-Image who are a great bunch of folks I have met before and are really tapped into FS/IT).

So, the role is two-fold: managing the delivery side of the business in the US in terms of delivery approach and project & risk management; and driving their marketing program as they seek to raise their profile in the industry. It certainly touches all of the things I was looking for in my previous post, and am looking forward to working with everyone at Lab49 and Write Image.

Agile Team Dynamics January 27, 2006

Posted by newyorkscot in Agile, Client Engagement Mgt.
1 comment so far

Most of the challenges some of our projects teams face are generally not technical — they tend to be business (or political) issues; a new team getting to know one another and evolving their style as a team; or, the team getting to grips with the business domain they are operating in. This is mainly the case when the team is made up of our staff, client mgt, client developers, and other consultants. In these situations, the team dynamics seem to be the most common thing we have to help teams out with. Politics are another (but never-ending) story.

I have been sitting in on some of the daily stand-up meetings, sprint demos, retrospectives and planning meetings on a few of our agile projects. It has been interesting to see the dynamics of these “cross-entity” teams at play as they follow the Scrum process. As is the case in most situations, you can’t just flip a switch at the beginning of the project and expect the entire team to be executing the process perfectly. There is always some coaching/mentoring/educating required to make sure EVERYONE is doing what they need to do. On one of the projects, during the Scrum and the planning meetings you could observe that boundaries of responsibilities were being crossed (e.g. Product Owner vs Scrum Master vs core team). So, one of the things we did (other than re-emphazing the process) was to have the team create and agree to some rules to help improve the team dynamics and to emphasize that they need to stick up for one another. The following rules were posted in the team room:

  • Emails should be BANNED for inter-team communication. If you have a question, issues, problem with someone on the team or the way things are being done, SPEAK to the person or the team.
  • Decisions made by the team UNANIMOUSLY should be communicated to the entire team – wikis, etc – emails ARE good for this. Examples, include decisions regarding designs, clarifications of ambiguities, development process, etc.
  • The entire team must UPDATE ALL TASKS in the Sprint Backlog before they go home at night. No exceptions.
  • The whole team is accountable for all tasks and estimates.
  • If you don’t agree with something that a team member says or does, or if someone puts you on the defensive, SPEAK UP and stick up for yourself and let them know how you feel (really feel – “Honesty Is The Best Policy”). If the team is not making unanimous decisions it is not working together as a whole.
  • If the team believes it has hit a barrier or estimates suddenly jump, such that THE TEAM thinks it will not deliver on time, then it is time to raise it to the Product Owner (for potential de-scoping). If the team still honestly believes that it can make the deadline, then thats OK – it just needs to agree collectively to get through the workload accordingly.
  • If(or when!) there are issues, problems, etc it is very important that the whole team understand the issues clearly and the entire team understand the solution. This way a) you all know what happened without ambiguity and b) the team knows how to deal with it going forward, and c) reduces dependencies on individuals.
  • There is no such thing as ‘lost time’ – either a task was not completed due to impediments or estimates are recalculated due to needing more time, or you put a task on hold and pick up a new one.
  • There is only one PRIMARY metric – deliver or not deliver ….

The result was that in the 3 subsequent sprints the team delivered when they said they would (and yes, there were 1 or 2 things dropped from scope), and you could actually see some pride and smiles in their achievements.

The reality of introducing agile to new clients and different IT organizations is that the change management required can be very tough and has to be constantly and diligently applied. It would be great if every client was up for doing every project in an ‘pure’ agile manner, but that is not reality. What we can do though is gradually educate and show them what it means to be agile and why that is a good thing. The retrospectives are really key for everyone involved but the changes needed to refactor the teams and organization have to be embraced by everyone.

Still running October 28, 2005

Posted by newyorkscot in Client Engagement Mgt.
add a comment

Client: Let's build a credit risk calculation engine for regulatory capital reporting purposes. We know this will take a lot of analysis and design, together with 12 months of development. We have preselected Hibernate as the technology of choice to help us with access to the Oracle DB. We know that we will have to crunch over 2 million transactions a day on a batch basis where we will need to load reference data and calculate credit exposures for every transaction. Remember also that we have just completed an optimized batch calculation architecture before starting this project that can do over 2million transactions in less than an hour.Finetix: What will you do in terms of :

1) Leveraging existing architecture

  • a) Definitely Use It
  • b) Do some analysis and figure out the efficiencies of re-use and gaps
  • c) No. New project. Let's build new infrastructure from scratch.

2) Ensuring that your system performs appropriately ?

  • a) Let's collectively review the architecture for performance purposes, once we have designed it (and maybe even build a prototype?)
  • b) Let someone else figure out we have not designed this properly for performance at some point during the development process, and then ignore them.
  • c) Decide to wait until we have finished coding and get to SIT/UAT to performance test whatever we have at that point.

Client Answer: ? 1(c) and 2(b) and (c).Client Results: a 68 (!) hour process to crunch 600k transactions, compared to doing over 2million in 1 hour. The cause ? The use of cursors that go row by row through the data in Java and query the database for each one. Chances of quick fix – none.

Nice work, guys.

Addictive Clients August 14, 2005

Posted by newyorkscot in Client Engagement Mgt.
add a comment

Our clients have addictive personalities. The number of times we have put people into clients on projects and can't get them moved on to other project is crazy.

The problem is as follows: a) plain and simple: our people are the best at what they do, and have a habit of blowing their clients away from a domain and technical perspective, b) SOWs come and go, and we all know that scope changes, schedules change, etc etc, so keeping SOWs in sync with reality is a tough job, and obtaining and keeping good people is a tough thing to do (once they have them, that's it in their minds).

It is the nature and culture of our people that they want to work on new and interesting projects (and so do we!), plus we want them to lead up new client and project opportunties.

So, how do you not upset your client when either the SOW expiry has come and gone and you have had other plans for your people, or you want to rotate them in a pro-active manner ?

Balancing your supply (sales pipeline) and demand (current staff allocation, bench and people you need to recruit) is the obvious thing, but reality is not that simple. I have always said look after your current clients before your future clients, and there are things you can do to actively plan and work with your clients. However, my biggest risk is always that clients DO get addicted to our people and sometimes you have to adopt the band-aid approach — rip it off, let it sting, then get on with life.

Client Meeting – Another Risk Mgt Sell August 2, 2005

Posted by newyorkscot in Client Engagement Mgt.
add a comment

A couple of us went to see a prospective client yesterday. To cut a rather long story short, they need a team of real heavy duty technical talent to build out their application and technical infrastructure since their current consulting firm does not have the wherewithall to get the job done.

We met with the senior manager who asked some obvious but pertinent questions. How do we structure projects in terms of risk and project management ? What controls do we put in place before and during a project ? How do we work with other incumbent groups in an organization, whether they are employees or other consultants ? How do we incentivize and motivate our staff to get the project done ? Many of these are general questions we take care of through engagement and relationship managent, project-specific structures, employee benefits packages, as well as team-based get-togethers, etc.

Ultimately though, once again it comes down to how we mitigate risk (particularly for a new client we have not worked with before): put a plan together for a series of quick hits of delivering functionality, demonstrate our value and potential, gain quick feedback, provide quality rather than quantity (and they will pay for quality), regular communication at the executive and project level, etc. And guess what kind of approach provides that …. ?!

Also, buyers of products and services tend to think of the things in a different way than those doing the selling or execution, so the message and approach of a project needs to bridge that gap. I have mentioned some ideas before on this. However, one can only address most of buyer's objections and issues so far. There is a philosophical difference in mindset in how different people sometimes think of these projects (ie CFO vs PM vs vendor). Fundamentally, how can you ever 100% guarantee scope, time and budget to any client without something giving and breaking the financial vaiability of the project ? You can't. So therefore don't even bother trying to figure that out.

It is about trust, shared responsbility and risk mgt. (see this on trust as well). If you can't get the first two, forget it. Problems, dependencies and issues happen on every project and sometime unexpectedly — your solution/ approach needs to expect and embrace this.