Talk:Software project management

Rewrite and Merger

I am working on rewriting and merging "Software project management" and "Project Management Software". Any feedback or suggestions would be appreciated. My current plan is to merge both pages into "Project Management Software"; thoughts? PMDude (talk) 04:19, 1 December 2009 (UTC)

As they are two completely different topics, this would seem to be a poor idea. Why do you feel the need to merge them? Kuru ^talk 04:31, 1 December 2009 (UTC)

Pitiful

This page is really pitiful.

Any knowledgeable people want to attempt a rewrite?

I'm taking a slow careful stab at it. Are there any layout examples anyone wants to recommend? -- April 27, 2023 - Rich Legge — Preceding unsigned comment added by Richlegge (talk • contribs) 21:51, 27 April 2023 (UTC)

Remove Open Source?

The last edit added a section on Open Source tools with no content... should this be removed? --HobbesLeviathan (talk) 01:41, 12 April 2008 (UTC)

Yes it should because this topic shouldn't really be about specific tools, tool specific references should be on the specific topic pages Richlegge (talk) 16:58, 1 May 2023 (UTC)

You're reposing to a post that is 15 years old and has no relevance to the article as it is today. MrOllie (talk) 17:01, 1 May 2023 (UTC)

Shouldn't the topic be deleted, removed, archived or some how not existing in the talk group then? Richlegge (talk) 00:14, 2 May 2023 (UTC)

Higher traffic pages are archived. On the very low traffic ones, like this one, no one bothers. MrOllie (talk) 00:19, 2 May 2023 (UTC)

Time to edit...

I just came across this page. Will try to find some scholarly stuff and edit it but will take time. Affan Laghari (talk) 13:52, 2 July 2008 (UTC)

Move discussion in progress

There is a move discussion in progress on Template talk:IEEE software documents which affects this page. Please participate on that page and not in this talk page section. Thank you. —RMCD bot 22:02, 15 June 2020 (UTC)

I agree that IEEE references should be minimized. Software Project Management is not the same as the various pieces of software development. Richlegge (talk) 17:01, 28 April 2023 (UTC)

Seems to be resistance to changes

This article is quite old. Should I edit this page and replace with modern content or write a new page/article. Richlegge (talk) 00:54, 28 April 2023 (UTC)

You should not be adding inline external links (see WP:EL) or removing/commenting out parts of the article. MrOllie (talk) 01:38, 28 April 2023 (UTC)

This is a learning process. I'm trying to fix this. It seems others have also tried an given up. Richlegge (talk) 17:03, 28 April 2023 (UTC)

Software development process

Since software development process has its own page, doesn't it make more sense to limit all the text related specifically to development in this page? It would seem to better serve the community to leave all the software development topics to those numerous pages.

Software Project Management is not "a process". A process is repetative, software project management is a unique activity for each project with a defined end, it is not "never ending" like a process is. Richlegge (talk) 15:53, 28 April 2023 (UTC)

We follow the reliable sources on this, not your personal thoughts. Also, please stop inserting references to the Project management institute into the lead of the article. Mentions of particular organizations are not what readers are looking for, particularly not in the opening section of the article, which is supposed to summarize this article - not provide links to other people's websites. MrOllie (talk) 15:40, 1 May 2023 (UTC)

Software development life cycle (SDLC) Software development proces exists as a seperate article in Wikipedia, so wouldn't it make better sense to remove the redundant text from this article and simply have an internal link to that page? Richlegge (talk) 19:01, 2 May 2023 (UTC)

PMBOK and PMI

If PMI a govering body of software project management, can an internal link to the PMBOK and PMI Wikipage be edited in. The software project management page links to nearly everything else, why not PMBOK and PMI? Richlegge (talk) 16:54, 1 May 2023 (UTC)

See my reply in the above section. Also: please don't open redundant talk page sections. MrOllie (talk) 16:57, 1 May 2023 (UTC)

It isn't redundant. This topicwas a much narrower scope. Why is a quote from so long ago considered to be the "defacto" definition? Was is IEEE included but not other govering and credential organizations? Richlegge (talk) 17:04, 1 May 2023 (UTC)

One might as well ask why you're so focused on mentioning a particular organization in the lead of this article, or why your own citation of a 12 year old conference paper is 'modern' - especially given that that conference paper is not specific to software projects, as this article is. MrOllie (talk) 17:13, 1 May 2023 (UTC)

See, now we can make progress when you are more specific about your objections. Was that so hard?

I will find a quote, the current one is from 2005, with a definition and suggest it as a part of the lead? Are you amenable to that? Richlegge (talk) 17:28, 1 May 2023 (UTC)

It is impossible to answer that question without specifics about the source and proposed addition. If it is more overemphasis on the PMI or the PMBOK I'll probably continue to object for the same reasons. MrOllie (talk) 17:41, 1 May 2023 (UTC)

In today’s rapidly evolving business climate, software projects require the application of software engineering concepts besides project management effectiveness abilities to deliver a successful project outcome.

Barghoth, M. , Salah, A. and Ismail, M. (2020) A Comprehensive Software Project Management Framework. Journal of Computer and Communications, 8, 86-102. doi: 10.4236/jcc.2020.83009. Richlegge (talk) 18:17, 1 May 2023 (UTC)

Also consider that software project management is not the same as Software Develpment Life Cycle (process), which is merely one framework of software development(building software). Project Management involves the other areas needed to deliver software to a customer(or target environment): cost control(labor hours, hardware usage, licenses), communications(project status to all, not just development team), schedule/time, scope(features/functions), quality(do only what it is supposed to), human resources(skills,availability,productivity), project risk(those other than software "issues" or bugs), integration/deployement(to customer), stakeholder(primarily non-dev team members) management. Richlegge (talk) 19:20, 2 May 2023 (UTC)

Proposed Article Lead

Software project management is the practice/discipline of managing a software project through multiple overlapping phases starting with conception/initiation and continuing through subsequent phases of planning, execution, monitoring, completion and close down.

Standards organizations such as International Organization of Standards (ISO), Open Geospatial Consortium (OGC), National Institute of Standards and Technology (NIST), Institute of Electrical and Electronics Engineers (IEEE), Software Engineering Institute (SEI), Project Management Institute (PMI) and others all provide definitions for Software Project Management. These definitions are used by organizations all over the world in their attempts to successfully deliver a set of software features to an identified customer.

<-- See Also section to have internal links to each of the above mentioned organizations --> Richlegge (talk) 21:14, 1 May 2023 (UTC)

I consider a list of standards organizations to be a non-starter, and what is with all the slashes? The opening paragraph of the article is supposed to be a simple introduction to the topic, and this proposal is anything but. Think of how you would explain this to a middle-schooler. MrOllie (talk) 21:17, 1 May 2023 (UTC)

Simple version:

Software project management is the discipline of managing a software project through multiple overlapping phases starting with conception, initiation and continuing through subsequent phases of planning, execution, monitoring, completion and close down.

I typically use slashes to allow others to pick their preferred word. Richlegge (talk) 21:30, 1 May 2023 (UTC)

Software project management is the discipline of managing a software project is quite tautological, isn't it? MrOllie (talk) 00:20, 2 May 2023 (UTC)

Software project management is the practice of governance used to progress a software project through multiple overlapping phases starting with conception, initiation and continuing through subsequent phases of planning, execution, monitoring, completion and close down. Richlegge (talk) 18:58, 2 May 2023 (UTC)

Here is one definition with a quoted source.

A software project has two main activity dimensions: engineering and project management. The engineering dimension deals with building the system and focuses on issues as how to design, test, code, and so on. The project management dimension deals with properly planning and controlling engineering activities to meet project goals for cost, schedule, and quality.

Original English language title: Software Project Management in Practice, 1st edition by Pankaj Jalote Copywrite @ 2002

URL = https://books.google.com/books?hl=en&lr=&id=FFXDbAE34KsC&oi=fnd&pg=PR9&dq=software+project+management+definitions&ots=Eijtb3_PN_&sig=PrD7FDMRbhjNpYbGUwWQX1tYVVY#v=onepage&q=software%20project%20management%20definitions&f=false

The current article seems to deal more with the engineering and not very much with the project management. I would hope we could modify this article at a minimum to include the latter and ideally partition the article into engineering and project managment sections.

-- Richlegge (talk) 22:07, 2 May 2023 (UTC)

Is software project management synonimous with Software Engineering Management? From the tone and direction of the current article, that would seem to be the case, plus there is no article in Wikipedia for Software Engineering Management, thus this must be the article, correct?

If so, here is a referenced definition that helps make that more obvious:

Software engineering management can be defined as the application of management activities—planning, coordinating, measuring, monitoring, controlling, and reporting — to ensure that software products and software engineering services are delivered efficiently, effectively, and to the benefit of stakeholders.

-- Chapter 7 Software Engineering Management, Software Engineering Body of Knowledge (SWEBOK) version 3 -- A Project of the IEEE Computer Society

===

As for "Software Project Management" terminology there is a software extention (SWE) to the PMBOK, Its desciption is:

• This standard, developed by PMI jointly with IEEE Computer Society, provides guidance on the management of software development projects and bridges the gap between the traditional, predictive approach described in the PMBOK® Guide and iterative approaches such as agile more commonly used in software development.

Is this something folks here would be open to?

-- Richlegge (talk) 16:58, 5 May 2023 (UTC)

Software development

Shouldn't some of the topics such as software bugs be moved over to software development article? Bugs and testing specific "issues" would seem to belong in software development article because they are "issues" specific to the software development team and are not the more general type of project level issues.

Below is the topic lead for software development:
Software development is the process of conceiving, specifying, designing, programming, documenting, testing, and bug fixing involved in creating and maintaining applications, frameworks, or other software components. Software development involves writing and maintaining the source code, but in a broader sense, it includes all processes from the conception of the desired software through the final manifestation, typically in a planned and structured process often overlapping with software engineering. Software development also includes research, new development, prototyping, modification, reuse, re-engineering, maintenance, or any other activities that result in software products.[1]

The project related "issue" are items such as costs, schedule, scope, communications, etc.... and are generally not software development specific. Typically, development team issues, or bugs, are not brought up at the project level.

-- Richlegge (talk) 20:56, 2 May 2023 (UTC)

That's referring to the same issues as Issue tracking system (for example). Issue tracking isn't necessarily just for the software developers, it is common to break down marketing, planning, and other tasks the same way. MrOllie (talk) 21:02, 2 May 2023 (UTC)

Bugs are way different than project issues, that is my point. Issue tracking for bugs and issue tracking for project issues is in fact different.

Issue tracking for marketing, planning and other "tasks" is also way different than bug tracking.

-- Richlegge (talk) 00:30, 3 May 2023 (UTC)

My point is that those systems (and the related terminology) are not exclusive to bugs. You are incorrectly conflating the two. MrOllie (talk) 00:33, 3 May 2023 (UTC)

Actually, I'm attempting to better seperate the two terms. Bugs are specific to the software development/engineering, not the project management. Project management uses the terms "risks" and issues.

-- Richlegge (talk) 00:43, 3 May 2023 (UTC)

Ok, what's your source for that separation? Spitballing on the talk page is all well and good but it won't translate into article changes without sourcing. MrOllie (talk) 00:52, 3 May 2023 (UTC)

You need a source for why software bugs are not part of software project management? Anyone with even 3 years of experience knows that.

-- Richlegge (talk) 14:37, 3 May 2023 (UTC)

WP:NOR and WP:V prohibit us from basing article changes on things that 'Anyone with even 3 years of experience knows'. MrOllie (talk) 14:50, 3 May 2023 (UTC)

Speaking as a software architect, things like testing, tracking and fixing bugs are absolutely part of project management. It takes time and resources to implement unit tests, integration tests, smoke tests for various environments. That includes developer created tests and automated scans (including for code quality, security vulnerabilities, test coverage). Failing to include those in planning means a rude surprise when resources suddenly need to do multiple tasks at the same time, important checks are missed or implemented far later than they should. Good project management is aware of those items and the impact they will have on project timeframes and budgets and plans for them. It's not about individual bugs, but the resources, tools and costs related to those that relate to testing and fixing issues that project management must plan and account. Ravensfire (talk) 22:18, 2 May 2023 (UTC)

Ravensfire, Unit testing, bug fixing and tracking are software engineering related tasks and don't typically rise to the level of project tasks. Testing is a very generic term. Unit testing is typically not on the project schedule, but integragtion and customer testing are. My overall thought is to help audiences better segregate the engineering (software development) and project management "tasks".

Think of it this way, "bugs" are things developers normally find. Defects are quality issues outside groups find and might impact cost, schedule and etc... Richlegge (talk) 00:39, 3 May 2023 (UTC)

Bug vs defect - yeah, often the terms are interchangeably used. My usage is greatly driven by how my teams use the terms. Honestly, I don't consider a story done until the developer has fully met acceptance criteria. Anything found via developer or integration level testing is still at the appdev level. Once it's beyond that point, issues found start to be more disruptive, even if found via QA testing, code scans, etc. The developer has often already moved to something else, so now project management must review, prioritize and task resources to deal with the problem. And that's where the project level aspect come into play. Planning (ie, are appropriate systems in place for logging and tracking issues; resources allocated for issue resolution) and aggregate monitoring (are we seeing much high level of defects than expected). I know we've had a fun time with a project that QA and user acceptance testing have been brutal, finding some significant unintended behaviors (uh huh, we call those defect, product team) and forcing project management to re-allocate resources and push multiple efforts 2-3 months.

From a project management view, my view is that planning for and monitoring at the aggregate level is relevant. If a single issue gets to a project level, oh boy ... It's gonna be a doozy ... (and had that happen ... once.) Ravensfire (talk) 20:43, 4 May 2023 (UTC)

That is my point, software "bugs" and tracking them are not project level. Issues are, one type might be a software defect. No one wants to communicate a "bug" got past development. Project level tracks issues, but not bugs. Issues do need to be managed, they come in all flavors, and yes issues occur after developer gets released sometimes. If there weren't issues, a.k.a. risks, in projects no one would need a project manager, right?

-- Richlegge (talk) 16:15, 5 May 2023 (UTC)

IEEE Software Life Cycle

Why is the IEEE Life Cycle referenced here, wouldn't it more apporopriately belong to Software development process ?

-- Richlegge (talk) 22:11, 3 May 2023 (UTC)

IEEE 16326 is on project management. This is the correct article. MrOllie (talk) 22:13, 3 May 2023 (UTC)

Isn't project closure missing?

In searching this page there is zero references to project closure. If software project management is a sub-set of project management, then doesn't it logically follow that project closure should be mentioned on this page or is there some resistence or reluctance?

"Project Management is the process of guiding a project from it beginning through its performance to its closure."

-- Book=Project Management for Dummies, 2nd Edition
-- Published by Wiley Publishing
-- Copyright 2007

-- Richlegge (talk) 22:26, 3 May 2023 (UTC)

If you have sources that talk about aspects of project closure that are unique to software management, sure. Otherwise there's no need to repeat stuff from Project management here. See WP:SUMMARYSTYLE for some information on how related articles are typically organized on Wikipedia. MrOllie (talk) 22:33, 3 May 2023 (UTC)

Something other than PMI, or PMBOK, related though, right? YOU don't consider them a valid source, correct?

-- Richlegge (talk) 15:58, 4 May 2023 (UTC)

Most of their material isn't specific to software, so it is largely off topic here. We've also had problems in the past with employees of PMI spreading their stuff in inappropriate places on Wikipedia, so many of us prefer to keep mentions of them to where they are absolutely necessary. MrOllie (talk) 16:06, 4 May 2023 (UTC)

OK, thanks for that insight. It helps cut down on my frustration level. I've always seen them as a valid standards body, but I understand how their past behavior would put a poor twist on things. I have downloaded the Software Engineering Body of Knowledge (SWEBOK) from Software Engineering Institute. It would appear to be more software specific and is a project of the IEEE computer society. Richlegge (talk) 18:24, 4 May 2023 (UTC)

Software Engineering Management v.s. Software Project Management

Suggested New Lead taken from Software Extension to the PMBOK® Guide – Fifth Edition

** Remember, this document is joint effort between PMI and IEEE.

In addition to creating new products, software projects are often undertaken to modify an existing software product,to integrate a set of existing software components, or to modify the software infrastructure of an organization. Software projects may also be undertaken to satisfy service requests, maintenance needs, and to provide operations support; however these activities may occur as low-level continuous activities; they are considered projects only when they are specified as: temporary endeavors that occur within predetermined timeframes to provide deliverables and outcomes.

I guess the question needs to be decided is if the desired subject of this page to be about Software Engineering Management or Software Project Management? It seems Software Engineering Management is the domain of IEEE and Software Project management is domain of PMI. It seems this is by mutual agreement of those organizations.

--- Rich Legge Richlegge (talk) 19:27, 19 May 2023 (UTC)

Still over complicated. Our existing lead is short, to the point, clear, and cites a secondary source (an independently published book) rather than a primary one. We should retain the existing lead. As to your other question: If you think a distinction should be drawn between 'Software Engineering Management' and 'Software Project Management', cite secondary sources that tell us what the difference is. MrOllie (talk) 19:47, 19 May 2023 (UTC)

I didn't mean for the whole thing to be the lead mind you. I was more simply siting a source and getting the idea out there. The current sources are specific to only IEEE and very out dated. So I was trying to address both, getting something more current, and both IEEE and other recognized expert source.

-- Rich Richlegge (talk) 18:44, 24 May 2023 (UTC)

The existing cite for the lead is a textbook published by O'Reilly, not the IEEE. MrOllie (talk) 20:41, 24 May 2023 (UTC)